 Wonderful. Well, I'm grateful to be able to speak and really been learning a lot. I've really been enjoying the conference here, got to meet a lot of people and I look forward to presenting this part here. It's a bit different than a lot of what I present. The back story, almost, we're almost there. So the title of it is about decentralized data markets. But the real thing about this is where do you see some applications between what we can do practically today with Blockchain and what we need to do with machine learning. I got asked to be a chair for like a mini conference. It was about AI and Blockchain, and so I had to go out and research to find out a lot of speakers and see the use cases to see what was reasonable to present there. Anything I can help? Sorry. I needed to go out and research the field, find out who the speakers were, and really what kind of use cases they were working on. After a while, we did put together a good track for this, and so I can show one of the use cases in particular. Also, I was doing some client work. I figured a lot of people talk about Blockchain, I should learn, I should dig into this myself and see, since there's a debate about Bitcoin, is it real, is it a lot of smoke. I wanted to find out about the technology, so I jumped into it and I had a client that was working to develop decentralized data markets, and I helped them on some projects. So this is a little bit of a report about what was learned. It's really more for the purpose of people who are working in data science, if you're not familiar with what's going on in terms of Blockchain technologies, and the kinds of use cases outside of speculation. It's more for you to be able to learn what the issues are, where some of the pointers are to learn more, and also to see what some of the issues are that people are working toward. There have been some breakthroughs recently, and so I will hopefully provide some good pointers to those. I'll keep going. All right. So the first slides or so were about, really I went out and talked to a lot of people, and it was fun because it's not just machine learning, and it's not just the crypto. It's also a matter of talking to people who are really expert in game theory, for instance. So that was really interesting to see where is this intersection between economics, finance, game theory, computer science, machine learning, etc. So I wrote an article that got some traction about decentralized data markets, and that article was exploring why is it that you'd want to do this, because to a lot of people it sounds like a bad idea. The gist of the article is this. If you're working in areas of machine learning where there's a lot of risk, can you really expect that one company will hold all of that risk? So for instance, when we're talking about self-driving cars, do we want to rely on just having one party be responsible for all of the enormous potential risk, or are there ways to share some of that risk? A good example would be if there are competitors, I don't want to pick on too many companies, but I heard of two different tire manufacturers, for instance, who were concerned about safety of what they're manufacturing. Even though they're competitors, they wanted to be able to build machine learning models to do some quality assurance. They didn't exactly want to share their data, but they wanted to be able to have some machine learning models in common. Also, I believe that this will help with regulators and just in general, it helped toward better safety, better products. So how is it that you could have people who are even competitors, maybe more than two, there may be many of them who work together collaboratively without necessarily sharing their data, but they could build machine learning off of the shared data. It may be that you don't necessarily want them to be able to get the machine learning models directly. So you might need to use some type of decentralization, you might need to use some type of encryption, and there have been some recent breakthroughs. Aha, okay, good, we've got this. Except for it says time's up. There have been some breakthroughs on this recently. And one of the problems when we're talking about blockchain, just to kind of frame this, is that if you look at technologies like Ethereum, they have very, very slow rates of transactions. And so people ask why on earth would you want to be using some type of database that's very expensive to use? Why would you want to use it if the transaction rates are very slow? What kind of benefits can you get out of this? And probably the simplest explanation on that is that a decentralized technology, it's actually something that's very common. We interact with something like this all the time. For instance, when you go and buy real estate, if you buy a home, just speaking about purchasing a home in the United States, there's gonna be the buyer, the seller. They both have agents, maybe more than one. They probably have at least one bank, although in the United States, typically you get your loan transferred to another bank right after you close. So there's probably multiple banks involved. There may be attorneys on either side. There's certainly going to be inspectors, government agencies that are involved looking at fire and flood and pest and other issues. So when you go to buy a home, it's not something that you want a fast transaction on. The idea of spending hundreds of thousands of dollars within milliseconds is not something you want to do. Instead, you wanna make sure that there's time for settlement so that the different parties can come in. They can explore what the deal is about. They can voice their objections or anything that needs iteration. And maybe the transaction itself doesn't settle for a matter of days or weeks. But you want that if there's a lot of money and a lot of risk on the line. So real estate escrow, real estate transactions are actually a really good analogy for some of the kinds of use cases that we're seeing with machine learning and blockchain. Let me check. Okay. So the article we'll have up here, it explores in a bit more detail some of these analogies. What I wanted to do was give some history, and I'll just kind of wing it. I wanna give some history on this. Definitely in the slides, there's a lot of links to looking at background information like when did ideas of blockchain first start to surface? And so people know about things like Bitcoin. There's a lot of speculation in cryptocurrencies like Bitcoin, and that leads people to say, well, maybe there's not a whole lot of technology here. This is just people trying to do some sort of financial scan. And certainly if you look at the markets, there's just been a downward plunge in the pricing for Bitcoin and Ethereum. So it's gonna show even graphs from today of how much that's been plunging. But the foundational technology is really interesting. And it goes back a lot further than people imagine. There's a great story about how a cybersecurity company has actually been publishing cryptographic data in the New York Times for decades and doing something that approximates a kind of blockchain. Again, they've been doing this for decades. And you can look it up in the classified ads of New York Times. They do this for security assurances, being able to get footprints out into the public. And you can look further back too and find examples of where these kinds of elements of cryptography, governance, decentralization, where they've been employed before. So I was trying to build up some history here. And again, the slides will have links on that. The point about machine learning, just to kind of drive toward it. The point about machine learning is that typically you have some sort of data set that's labeled when you're doing supervised machine learning. And a typical kind of approach is that you'll do a holdout. You'll retain part of the set for training and then other parts for testing. In the notion of decentralization though, some of that changes. So I guess first off, I should try to describe for people who haven't had a lot of hands on with this yet, what we mean by decentralization. If we talk about having one computer, one database, then we've got a very centralized kind of resource. There's not a lot of worry. There can be security parameters on it are very well-defined. For the kind of technologies that we do here, talking about typically at Big Data Spain, we talk a lot about distributed systems. So there's more than one server and the data may be distributed across many different sources. There's a number of techniques, of course, that we've used in things like Hadoop and Spark and Kafka, which represent distributed systems. Being able to make sure that we can get reliable results from the data and be able to work with clusters of computers. Decentralized though is very different. Decentralized is to say that there's no real one controller. And so with distributed systems, typically you do have some type of controller. With Spark, of course, there's some type of master. There's some sort of Spark context that you're going through to reach that. We decentralize though, what you want to do is make sure that no one party has control over all the others. And that's a difficult thing to do. The math of things like Ethereum, they've worked out a lot of principles for this. They're finding some problems, but they're working further on it. So decentralization is an interesting thing because then you can have multiple parties who can work together without a fear that one of those parties will take over control. And so that's the notion of having competitors, for instance, work with data sets that are decentralized. Each different competitor could have their own component of the data, but yet the training of the machine learning models can go across all of it. So decentralization is a hard problem, but definitely when we're looking in terms of O'Reilly media and some of the surveys and forecasts, trend analysis, decentralization is very much a long-term theme. And there are a lot of reasons for it. Ultimately, anything that's centralized has a lot more potential security, vulnerability, a lot more risk. So decentralization can help to try to mitigate that risk. So there's also another problem though that technology such as Ethereum, which on the one hand are really good for proving out concepts like smart contracts, token curated registries, distributed apps, et cetera. Even though they're really good for that, they're not entirely proven yet. And so a concept that's emerging amongst people working with decentralized data markets is do people have a trade-off and look at a particular use case and try to understand which parts of it need to be decentralized versus which parts need to be centralized. So for instance, you might have a data set that's shared amongst competitors and it may make sense for the metadata about that large machine learning training set to be decentralized. However, the data itself may be so large that you want it to be centralized. So you could use something like IPFS as a means of decentralizing the metadata, but the data itself would be pointed to in some sort of buckets in Amazon S3 or Google Cloud Storage or Azure Storage. The cloud providers by definition are distributed but they're not decentralized. They're still centralized. And also when you look at applications, you have to break them down. There's matters of identity, authentication, privacy, storage, et cetera, involved in any kind of application you're working with. Some of those may need to be more centralized or less centralized than others. So the use case that I wanted to show was in healthcare. It's actually in cancer genomics where they're able, oh. And then, Paco, as the presentation is not going. Yeah. And I see your face, you are suffering. Yes, exactly. Can I do some magic to you? Probably, yeah. To show that sometimes things are really hard. Things are hard, yeah. Okay, big applause for him and bring me, please. Come with me, Paco. Thank you. Come with me, Paco. I'm gonna show you something and I need your help. Come with me to the stage, to the center. This is for me. Bring me the glasses. Come with me, Paco. Take over the... Okay. Okay. Is there a scorpion in here? Not a scorpion. But the hard part of the show, it's always for you. So take over that. Okay. Okay. And put it in the middle. So, put in the... Okay, great. Put over there. Right now, I brought here... Oh, okay, okay. Okay, 200 bottle of glass. Okay, good. I don't know if the ones that are in the back, in the cheaper rows, you can see well or not. Pinking glass, man can't tell. Que bueno la dicha. It's real one. Look like glass. Real glass. Sounds like glass. We'll be breaking. I cannot see. Okay, here. Real? You go. No, you can touch it. Okay, perfect. Sometimes in our life, this is your rod. Take the hammer. Hammer? Take the towel. Come here. Okay. Come with me. Okay, okay. Fold the towel over the... Oh. If you unfold first, it's gonna be better. Okay, okay. Short cuts, short cuts. Take with your hands and think of one of your boss. My boss? Okay. Not your own nowadays boss, you don't... Oh, boss. All bosses, okay. Go down and hit. This one here? With your left hand. What then? Take the neck of the bottle, that's it, and hit with the right. Go, Laura. Is that good? Yeah, yeah, go. I'll let you. Okay, let it be this. Okay. And sometimes in our lives, the life is harder, really hard. I would like that for the first time in these two days, think of the most important person in your life. Think of yourself. I would like that you are the most important person in your life. You don't love that because I promise that's the key of the life. I would like that you think of yourself and think of a dream that is in the outside. Nathan, you can do it too. And those that are back, if you wanna come closer, will be better. Okay. So, can we put all that? So I can hear it, okay. So, each of you, think of your dream for the next 15 seconds. Neuroscience says that the best way to achieve our dreams is to know that they are not really easy. Blockchains and all that you have been saying, it's not easy. And artificial intelligence, it's not easy. But you have to dream of that and make it real. For all of you, can we put it in the screen so I can see? All right, I can move. Okay. Can we put the sound, please? Come with me. I gotta ask you, is there something over my shoes? Is there a special shock or something like that? No, no, no. Over my foot too? Barefoot, barefoot. No foot? Absolutely, yeah. No special shock? No nothing? No nothing? Thank you so much for this time. Ready? Everything is ready for Paco? I should take my stuff. It's present. Now, you should continue with your presentation. If you do it properly, great. If you are doing not so good at the end, you go across. That's the deal. Big applause for Paco, and it's his time. Big applause. We'll start it this day. Paco, what I say, I promise, at the end, if you like, it's gonna be free for you. So we're gonna let it over there. Okay, great. Paco, nice and you. Okay, thank you. We used to say that in big data, if you have a hammer, everything's a nail, and that was for how to, but I think now if you have a hammer, everything's a wine glass or a wine bottle. A correct one is now? Perfect. And if you're taking more time, less time to talk. More time to walk. Less time for talk, more time for a walk. Great, okay. If you wanna get the slides here, you can download, there's a URL for it. So there's a lot of links in here if you wanna research more about this topic. Great. Alrighty, so there was this article about decentralized data markets, kind of exploring some of the ideas of shared risk, and when is it that in machine learning, especially for things that are really in front of the public, where we do share a lot of risk, where we're driving on the roads and some of the cars maybe are automated, or other situations where there are public interactions and part of it is being automated, part of it is being driven by machine learning. So for definitions, again, centralized, distributed, decentralized. And so if we talk about having your own data center, your own computer, your own database, and all of your traffic goes through, the app just goes through that one set of resource that's centralized, you own it. Distributed cloud is a pretty good definition for what's going on with distributed. It's in a lot of places, but there's still some sort of central control plane. So we have ways of making sure that the different parts aren't out of sync, split brain, things like that, but it's not decentralized. Decentralized is when there's no one part that has control. Now, the thing about the blockchain kinds of technologies, here's charts from this morning showing what are the relative ownership for both Bitcoin and Ethereum? And Ethereum is the one here on the right. You can see that really like half of it is completely controlled by just two parties. So if they cut a deal together, they pretty much own the whole thing. If three parties cut a deal, they definitely have a majority. It's not quite decentralized yet, but it's a mechanism for getting there. There really are a lot of parties and this can change, it does change over time. So data markets are interesting because where do you get the data that you need to be able to train important machine learning models if you don't own that data already? Probably you're buying it from somebody, you're partnering in some way. There are mechanisms for being able to have data markets, but some of the issues are if you have interesting data, data exhaust from your business for instance, or you're developing some interesting data sets and you're curating them, how can you sell them? How can you, who governs the usage of those? And really what's to prevent somebody from buying your data, collecting all of it and then going and reselling it? That's kind of a difficult issue. So that's why some of these centralization technologies are interesting because they might be able to help these problems in particular. But blockchain, even though it's been around for a while, it's kind of going through an AI winter. I mean, I'm not gonna predict that necessarily, but if you look at the charts, things don't look so great. So as far as speculation, like for instance, this came off of NVIDIA and this came out today. It was an article about NVIDIA pulling back GPU for blockchain mining. I think they've actually closed that business unit. It's just because the profit margin's not there anymore. Okay, and even there's a lot of controversy. Even William Shatner is jumping into the controversy and he's able to quote specs from Ethereum, which I thought was pretty impressive for William Shatner. Okay, so some background on this. Decentralized is where you don't have everything stored in one place. It's not controlled by any one party. Blockchain is where you have blocks of data which are decentralized, but they're still linked through various forms of cryptography. And it provides the idea of a distributed ledger, something that's accountable. So Bitcoin, Ethereum, et cetera. Proof of stake is something that you'll probably hear. It's a way to be able to have validation that someone has ownership in a decentralized property. And it's in contrast to proof of work. So when you hear about mining on blockchain, it's because people are running a lot of CPU time or GPU time or ASIC time, whatever. They're running a lot of hardware to be able to go out and find cryptographically little gems that are hidden out there in the mathematical vector space. And if they can find those, they can prove that they've done work, which is to say that they've actually helped to calculate the transactions that are required for the distributed ledger. But they burn up a lot of energy. Proof of stake is a different way to handle that. It's a way of essentially having some distributed ownership and some decentralized ownership, I should say, which doesn't require all the electrical requirements on top. A smart contract is where you can have some code that's stored on the blockchain, which other people can execute. And the code executes a kind of like a legal contract. So there's API transactions that are extremely well-defined. And by executing these, you're able to do a transaction. Now, on top of that, if you have smart contracts, you can start to build other types of mechanisms. One of them that's very interesting, it's called a TCR. It stands for a token curated registry. So essentially think of this. If you had an API where you could manage a list, it's just a list of items. And you have multiple people who own that list. They share ownership, but it's decentralized. So no one party has control over it. And what you can do with the list, it's like what you would do with any computer science data structure with a list. You can add, delete, maybe, I don't know, prioritize or update elements. But you go through that API using smart contracts to be able to curate a list. And this is where it gets really interesting because the list can basically be different segments of a large data set. Something that's used for training machine learning. There's also something called a DAP. You'll run across. It's a decentralized app. So how can you build an application on top of smart contracts, for instance, to manage something like a token curated registry? And oftentimes these will have some server side component plus maybe some mobile app component so that people can interact with whatever is being curated on the list. So to tie this all together, a decentralized data market is where you have pretty much all of the above and you're using DAPs to be able to manage buying and selling data. Or using data, or using the products of the data, such as machine learning models that were trained off of them. Okay, so in the interest of time, let me move forward. If you want to check out the original materials here, smart contracts by Nick Szabo. There's a couple of versions of it, but it was published in the Extropian Zen like in 1994. And then subsequently, the white paper and the yellow paper, the sort of the abstract paper and the implementation paper for Ethereum came out 2013, 2016. TCRs were described first off by Mike Golden really just a year ago. And here's the GitHub repo for the original TCR. There's several others that have been based off of this kind of mechanism. Okay, so the thing that makes this different is the code that goes out onto blockchain, it runs on a virtual machine, the Ethereum, the EVM. And it's basically bytecode, a lot like what you would do with Java. The thing about it though is that once that code, once the code is put out there on the chain, you don't want to change it. You don't want to iterate on it. There's no bug fixes. Once it goes out, it's out. If you go back and try to iterate on the code, you can introduce a lot of really bad potential security problems. So you have to make sure that when you're building up these contracts, the code has to be perfect before it goes out. And this is where a lot of auditing and a lot of game theory come into play because you really have to be certain that your code is verified and that it's gonna work correctly, it's gonna work as expected. So a mutable code on the blockchain, that's a very interesting thing. Another way to look at this is with virtualization, right? I mean virtualization started out with VMs and software virtualization going into hardware virtualization, you started seeing things like hypervisor and we got notions of Amazon AWS. Then we started moving into things like C groups, LXC, which led to Docker and Kubernetes and Mesos and many other things that we use now, SystemD and others. And so there's been this trend of getting lighter and lighter or lightweight virtualization. Arguably serverless is kind of an idea that's a little bit more lightweight than what we would think of deploying Docker containers even though behind the hood there probably aren't some Docker containers. But what's going on with smart contracts is sort of like way, way out on the scale as far as super lightweight virtualization. There's just a tiny bit of code, it's really well known and it is effectively serverless. Okay, so some earlier history. There are good parallels here. So I just, I wanted to throw out something that's a little bit strange, but if you look back into the 16th century, there are very bizarre alchemical documents talking about forming this fictional thing called the British Empire. Long before Britain could ever be called an empire. But when you look in those, actually they were practicing types of encryption very early. They were working with cryptography. They were also working off limited liability, a risk mitigation. And they were doing voting shares, governance. They were also looking at a lot of data collection. So it's really interesting when you go back and dig into those early documents which are now housed in museums in London. Those things led immediately to the first public corporation, the East India Company, and to subsequent things that led to constitutions. But these were early ideas about decentralization and there's a lot of parallels between what the people in blockchain are doing now and what these people were doing hundreds of years ago. I'll move forward on that. If you've ever seen a play called The Tempest, it covers this in detail. And even though those are primitive, they were early forms of decentralization. But the one that really started it out is something that's barely known. It's a paper called How to Time Stamp a Digital Document by Haber and Stonetta and they were working at Bellcore, a spin-off of AT&T Bell Labs. And so they published this and they had an application based on it where they were doing cryptographic signatures published in the WAN ads of New York Times. And so that's been going on since 1995. So it may be high tech, but not necessarily. Now the problem is that when we talk about blockchain, really we're talking about distributed ledger. It's a kind of database. And so when we think of like distributed databases, we wanna get very fast access times. But these are painfully slow, they're super expensive and they're exposed to all kinds of people. I mean, basically everybody can inspect what's on them. So they're sort of the opposite of what we try to do when we're building distributed systems these days. But there's reasons for that and this is what I tried to mention. The best analogy that I could find is escrow for real estate. When you're doing a real estate settlement, you've got hundreds of thousands of dollars or millions of dollars euros transacting between different parties and you have a lot of auditors and regulators and whatnot who are inspecting the house and inspecting the loan. And you don't want those transactions to happen quickly. You want them to be painfully slow. You want them to be expensive because if there's mistakes, it'll be a lot more expensive. So there are really good reasons to have this kind of fundamental tradeoff between transaction throughput and the degree of centralization. Again, the centralization is what introduces risk. So if you want an example, here's a tutorial that I helped to write. This is off of computable labs. It's some open source, mostly JavaScript. It's an implementation on top of the original TCR that I showed earlier on. But it's how to maintain a distributed app and a token curated registry. Basically it's a list of universities. So it's a decentralized database and there are people who can go in and add to it. There are people who can go in and consume from it. So you can see all the basic operations but you can get this running on a laptop really simply. And again, this is JavaScript and so it's running in node mostly. So one thing that you could think of as an application for this, if you, for instance, ran a winery. You had a vineyard, you made wine. Instead of having like a wine club that people pay a certain amount every month or every year to get shipped wine. Instead, you can consider part of your annual production, your wines, to be a kind of listing. And this, in this way, by using something like smart contracts and TCRs, people could buy into ownership of that list. So the winery starts it out but they get other people to subscribe to it and so now they have multiple owners for that batch of wine, that specific vintage. Some of the people are gonna drink the wine. I know, seriously, I would hear and by the looks of the floor, there are many wine bottles there. So the list will have deletions and the value will change but if it's a really good vintage, overall the value of the unit items on there will go up. So there's some economic curves involved in this and it actually makes a lot of sense that if you have something which, you know, the transactions are few and far between, this is a way of being able to have smoother curves, price curves for buying and selling and effectively creating markets out of things by tokenizing them. So it's interesting for being able to create markets out of data. And so here's an idea of, if you could have distributed, sorry, decentralized data and decentralized models, machine learning models, there could be transactions then between using the data, either for training the model or for some type of inference and being able to get access to run the model or evaluate it. Now the thing that's not common in the dialogue is about this trade-off between fully decentralized and fully centralized. Right now when we look at cloud-based solutions, these are primarily centralized. When we hear people talk about blockchain and Bitcoin, those are mostly fully decentralized arguments. But what we're finding is the interesting use cases combine elements of both. And so again, when you look at the characteristic properties of data sets, you're concerned about privacy, storage, reliability, verification, identity. Almost each one of those has a trade-off between fully centralized and fully decentralized. And depending on the use case, you wanna adjust the knob one way or the other. Okay, I'm gonna skip through parts of this here, except to say that collecting and curating large data sets and doing it 100% correctly is a really hard thing, even for teams that are extremely expert. And so as we begin to rely on more and more automation, more and more AI going out into the public sphere, again, self-driving cars are a good example, but there are a lot of other places where automation is doing something that affects the public, such as security in a shopping mall. Trying to get air-free data sets, I don't necessarily believe that any data set is 100% correct, so there are going to be problems. And so there's going to be risk associated. Are there ways that we can decentralize to avoid some of that? So again, instead of having one company be responsible for collecting the data, cleaning it up, and also auditing it, is effectively they're auditing themselves. Are there ways that we could have not just one company, but more than one company, in a given vertical, collaborate on decentralized data sets, but also get their auditors involved, and also get their regulators involved, and also get the watchdog journalism people involved as parties in something like a TCR? That would make a lot of sense, and it's a good way to be able to guarantee some of these controls on privacy. Okay, I'm going to scoot through, because I know that we need to make up some time here. So I want to talk a little bit about some latest breakthroughs in state-of-the-art. And just to preface that, when we talk about attacks on decentralized infrastructure, I mean, I have some background in network security, I did that years and years ago, but I still try to keep up. But when I was hearing about the attacks on smart contracts, it was nothing recognizable. It was nothing like what you would see with, say, web apps being attacked. And instead, the kind of exploits that you're talking about, these are ones that are very familiar to people in finance. So if you're trading stocks, you know about things like pump and dump. These are financial exploits, they're game-theoretic exploits, and these are the kind of areas where smart contracts, TCRs, et cetera, find that they have a lot of vulnerabilities if they're not done correctly. So it's interesting because cyber attacks in this area are probably more informed by people who are financial traders, or for people who, again, are working in economics. But it's not new. And so as a point of encouragement, I just want to say, we've been dealing this for a long time. This is interesting, I learned here. The first cyber attack was in 1843 in France and two bankers, they bribed a telegraph operator. They had a kind of system of telegraph based off of, like this big wooden semaphore that was on top of a tower, and people would be able to see it from a distance and record what symbols were being transmitted. So it's a very early, non-electric telegraph. And anyway, two bankers in France bribed one of the operators to transmit false data so that investors in a bond market would be tricked. It's really funny, but I mean, basically network attacks are as old as networks. So bringing that forward, here's a really good survey of what's going on, this is from Ben Lorica, recent article about liquidity for data in the age of very strong privacy controls because of things like GDPR and what we're seeing on it. I don't know if a lot of you have heard that California recently passed legislation that's very much like GDPR and it goes into effect in about a year. So I mean, we're going to be contending with this kind of thing all over the world. And companies that have interesting data typically have some type of centralization, some type of silos. So how can we get out to allowing for data sets to be private but also auditable? And so here's a great interview. If you haven't seen it, this is one I'd point to probably the most, it's from Alon Coffman. It's a company in Israel called Duality. And one of his co-founders is a very famous computer scientist mathematician, winner of the Turing Award, plus many other awards in mathematics. They have a really amazing company. This is an interview that they did on O'Reilly recently and they talk about different forms of cryptography that can be used for decentralization. So how can you have it such that multiple parties are working with data sets and machine learning models? No one party has control and in fact people may not be able to see the data but they can use it. And vice versa, they may not be able to get a copy of the machine learning model but they can use it. There are really three forms right now. There's homomorphic encryption. You'll hear this called HE and there's a Python library that's popular called SEAL. You'll hear about differential privacy. Apple has pioneered a lot of this. You'll also hear about secure multi-party computation. All of these are different forms of distributing privacy problems, privacy preservation in distributed computing. And all that can be used for smart contracts is definitely some great approaches here. They all have trade-offs. Some are a little bit more toward helping out the people who are consuming the data. Others are more toward helping the people who are producing the data. But the thing is you can combine them and so that's what duality is working on. The URL for it is duality.cloud. I think they've got a really fast, fantastic future. But the thing is that all of these have been horribly expensive to compute. And so the problem is that what you do is you inject noise in a very well-known way and that beefs up the privacy. You can still do computation even with noise in the stream. And in fact, in some cases in machine learning you may actually improve machine learning models because it's one way, like ridge regression, it's one way of getting away from overfitting. Here's another great interview from Cheng Liu from Georgian Partners, some of the work that they've done within their portfolio. And I've linked that to a couple of the main papers in this field. And the reason why I'm giving this is that a couple weeks ago, there was a real breakthrough. This is coming out of Singapore and even though homomorphic encryption has been terribly expensive, they were able to get much better performance. They have a solution using GPUs. It's something that could be run in the cloud. They actually found identified errors in previous implementations such as SEAL and they've been able to beat some benchmarks pretty seriously. So I think that the world is just starting to digest what the ramifications are of this, but we're gonna see it being used in applications. And with that, I'll just go through one example. This is really great. It's from Rob Curry at UC Santa Cruz. And this is the group that beat the whole competition on human genome. So it's a really fantastic group of scientists. They created a joint venture, if you will. It's called the Cancer Gene Trust. And so essentially it's a way for people who are everybody on the token list is a terminal patient with cancer. But the point is that cancer is a genetic disease. And so genomics are really interesting here because if you have your personal genome information, if you contract certain forms of cancer, there's a very high likelihood that somebody else in your family will also have that down the road. So this is a really terrible data set to look at because basically everybody there is giving data about themselves knowing they're gonna die. And I pulled out like there's some JSON that's showing some data on one of the patients. But it's really amazing because this is entirely based off of Ethereum and it's decentralized using IPFS. And it's probably one of the better dapps as far as utility that we've seen so far. And again, the thing is you really want strong privacy controls because this kind of data could potentially be very bad if it got out into the wild. So healthcare is a place where you're gonna see a lot of interesting work in these kinds of decentralized applications. And so with that, thank you for bearing with me. The slides are online. I'll post about them in the URL as well. And I'm gonna have office hours in about one minute. Thank you very much.