 Ac rwy'n credu i'n gwybod y cofnod o'r gwasanaeth ar y cydwyr o'r project Oceon. Ac rydyn ni'n credu i'r cydwyr o'r cydwyr o'r cydwyr o'r cydwyr, mwy oedd yn gwneud o'r cydwyr sydd hynny, yn ei fod yn oed yn ymddangos ar gyfer erbyn. Felly, rydyn ni'n credu i'r cydwyr o'r cydwyr. Ac rydyn ni'n credu i'r cydwyr o'r cydwyr o'r cydwyr o'r cydwyr o'r cydwyr. I would like to show you how we're doing it, some of the techniques, how it works, maybe some ideas for people to try out in your different projects as well. So, what is OCEAN? OCEAN we describe it as a decentralized data exchange protocol to unlock data for AI. And I think OCEAN came out of some observations. And the observation was that in the AI space you've got these amazing startups, researchers, you've got great machine learning algorithms. They can do amazing things with deep learning and generative networks and all of this stuff. But they haven't really got much data. And if you want to get good results out of machine learning models, you need to have a lot of data. And particularly when you're doing predictive models, this kind of stuff, the more data you have, the better your model is going to be. Data beats algorithms when it comes to modeling quality. At the same time, you've got all of these multinationals and governments that are sitting on vast amounts of data, but really haven't got the skills or the talent, AI talent, to actually take advantage of it all. And often the data is like locked up in silos, even within those organizations. So they can't actually bring it together and do anything useful with it. And as a result of this, there's only a few companies that are really maximizing the value out of AI right now. You've got your Google, Facebook, the people who both have a lot of data and a lot of engineering skills in-house that they can actually take advantage of it. And the challenge ultimately is how do you actually decentralize data so that you don't have to have all this vast amount of data under your own arms in order to take advantage of AI? And Ocean's founded really on a vision of liberating data so that AI can really achieve its full potential and that everyone can participate in it. It's not just going to be a monopoly between a few companies. So Ocean was founded by two companies working together. One is DEX, which is a company based here in Singapore. Been here for a few years and has done a lot of data marketplaces. So traditional marketplaces for data sharing. I don't know if you've ever been to any of the hackathons in Singapore. They supported a lot of the hackathons with like data sets and gathering data and data sharing agreements. And the other company is BigchainDB, which is a Berlin based blockchain company. So yes, we have some blockchain in this one. So I always think that if you've been in functional programming for a while, the blockchain you always find is vaguely amusing because it's basically just a long link list immutable. Yeah, been there done that. But we are using blockchain. We're using blockchain to help build the substrate for the Ocean protocol. And I'll say a little bit about why we're doing that. I mean, basically data sharing has been done for years. But it's a messy business. Yet you often have to have these very complex, bespoke data sharing agreements. There's tons of lawyers involved. There's lots of contracts to write. You often have to build some custom technology, agree what you're going to deploy where, who's going to open what ports. It just gets messy and complicated, particularly if you're trying to do it securely. And this makes it, this is a barrier. This is what was one of the big inhibitors to actually sharing data. And what we're trying to do with Ocean is basically to look at it. Well, what's it going to look like in a decentralized future? Well, first of all, we can't have all of this manual building of new solutions every time what someone wants to share data. We want to have a protocol. Yeah, a way of sharing data that's efficient and well specified and means that you can actually automate these data sharing processes. We want to be able to create markets for data. So, I mean, you've got, it is ultimately a market. You've got people who have data and you've got people who want data. So, we want to create the ability for incentives and marketing incentives to actually help people to trade data effectively. The blockchain gives us the ability to exchange value in that way. And it also gives us an immutable provenance. Yeah, exactly what transactions happened. And this is very important in many cases. If you look at things like, for example, clinical trials, medical research data, if you're building a medical device and you want to put AI in your device and that's going to control the dosage of drugs given to a patient, you better be sure you know where that data came from, how that model was trained, exactly what the provenance of that was because, you know, there's some significant patient risks if you get this stuff wrong. Likewise in finances, audit requirements, etc, etc. Blockchain also gives us the opportunity to do things like cryptographic proofs, like can you prove that someone delivered the service that they said they were going to? And this is a lot better than having people manually check and having some kind of, you know, legal dispute or commercial dispute resolution process at the end. And the blockchain gives us a token, a way of actually exchanging value in a way of actually buying and selling data. And I think the final point is, you know, instead of having these sort of point to point integrations where company A says we're going to sign a data sharing agreement with company B, we actually want an open ecosystem. Yeah, so everyone can participate and, you know, everyone's on a decentralized level playing field. And that's a lot of words. I mean, I think I'd just like to draw an analogy very quickly. We talked about the exchanging data, but a good analogy is in fact the trade in a, this is a global trade in manufactured and physical goods. Yeah, so world merchandise trade. And what you can see from this data is that around 1970, there's this sort of explosive growth in world trades kicks off. And anyone know what happened in 1970? Wasn't born? Surely you're a student of economic history. You've seen these things, no? Okay, so what happened in 1970? Some people say shipping containers. And that is actually very, very close. It is to do with shipping containers. But shipping containers existed a long time before 1970. What actually happened in 1970 is they standardized the containers. Yeah, so instead of having all different containers of different sizes and different shapes and different materials, they said, okay, we're going to define some standard container sizes. Docker. They started using docker. Exactly. Yeah. So ISO did docker way before docker did. But the point about having a standard on these things is containers work if you don't have a standard. But if you want to build infrastructure that uses containers, moves them around, lifts them off ships, big ships designed to fit the most efficient possible number of containers, the infrastructure around containers requires standard sizes to be used. And that's what we're trying to do with Ocean effectively, create the standard for data exchange. And the result of that, of course, is we want to be able to create supply chains of data. I won't go into the details of this, but this is like a healthcare case where you've got some patient data that you want to use to predict the risk of disease or, you know, like risk of stroke, risk of heart attacks, et cetera, which is an important thing to be able to predict. But you need data to train the models in order to actually create accurate predictions. And a principle of Ocean is that some of the data can stay within the secure environments of the healthcare providers or secure third party. And it never actually needs to get revealed to the other parties in the ecosystem. So how does it work? We've basically got at the centre of the network, we've got keepers and verifiers who are basically running the actual blockchain part. But that's really just the core. Around that we have, I guess what does the heavy lifting in the ecosystem is data marketplaces. So you can actually go to discover data, buy data, trade data, and service providers. So service providers can be like providing storage, or they could be providing compute. Don't if anyone, anyone uses Spark? Yeah. Okay, so it could be like a Spark compute cluster could be a service provider providing compute operations on some big data sets. And then around that you've got all the users in the ecosystem. So people publishing data, people consuming data, curators, referers, etc. So it's an ecosystem model. I mean, as Ocean protocol, we're trying to define the standard. We are not going to build all of the solutions or all of this. It's going to be totally open source. So everyone can build what they like on top of on top of the standard. There is a token, which is implemented in the network, which is a means of value exchange. So you can say, if you provide me this data set, I'll pay you 10 tokens, or whatever. It's like a, I think of it like a fairground token, you know, when you have like the ride tokens, let's go around the ferris wheel. Okay, so get some more interesting techy stuff. So this is kind of the very simplified architecture of a traditional data marketplace. You would have a publisher and a consumer basically uploading an asset into storage and downloading it after the asset has been purchased. And it's just one central location, which is fine. I mean, it works. The thing is that that only works on some assumptions. So the assumption is both the publishers and consumers are going to come to the same marketplace. Maybe, maybe not. And it also assumes that they're willing to store their assets, their data, in the marketplace. They're trusting that centralized authority to protect their assets for them. So that works for some people, but you know, it doesn't, it doesn't scale very well. A next step would be to actually add a blockchain on the bottom of this. And so it's the same architectural model, but instead of just having the marketplace, you now have the advantage of having a decentralized network so you can actually check the provenance. So it's a public chain. You can actually say what transactions happened. And anyone can verify that. You don't need to trust the marketplace. Yeah, that's a publicly verifiable thing. So it's already given you some greater decentralization and the ability to trust actors in the ecosystem more. You want to get paid if you're selling an asset. But it's still got the problem that all the data is being stored in this one centralized place. And of course, the data is getting downloaded. Now some data, you actually don't want to give the consumer the raw data. And a good example of this is like healthcare data, where, you know, there's great value in the healthcare data for training AI models. But most in most countries in most medical institutions, they're not allowed to share the data. You know, it's patients private data and they can't give it out to third parties. So the next extension is to do things like trusted compute. So in this case, we're saying the data goes into a secure environment, some kind of secure trusted third party. And the data itself, the gray box never actually leaves this environment. It stays in situ in that environment. And the only thing that a consumer can do is they can request some algorithm gets run on that data and they get to see the results. So the compute is actually being done within a secure environment. And this is a big improvement, because this now means that a publisher can create value from their data without that data ever going, getting out released into the wild, where, you know, there'd be maybe a breach of their legal or ethical obligations. And this is actually useful in a lot of cases. It's a very generic model of computation. So the output could be like an aggregate. You've done like a select group by you've got some aggregate results that you want to do in some business intelligence. It could be a model training. So you run it on the training data and the outputs is in fact a trained model or the weights for a neural network or something like that. It could be a data cleaning operation. So you're removing bad records or you're filtering the records in some way and creating a subset of data that is appropriate to be delivered to the end customer. So it's a very flexible model. A lot of real world use cases can actually be addressed with this kind of model. Of course, it's still putting everything in one place. Yeah, it's still got this sort of secure enclave. So the ultimate goal is to get to a point where we have fully decentralized services. So a publisher and consumer can use different marketplaces. There'll be service providers offering storage. There'll be service providers offering compute and algorithms and different people in the ecosystem can add value in whatever way makes sense. Let's say you're a startup and you've got amazing algorithms for data preprocessing and cleaning. Yeah, maybe boring, but that's actually extremely valuable if you've ever done any data science. You know how important it is to have good clean data. So they could actually just sell that service and that's all they do and people can then piece together the different services, the different data assets to sort of deliver whatever kind of solution or what kind of output they want. And that's what we mean when we say we're heading towards a really decentralized model of data supply chains. And of course, it's all enabled by the protocol and by the network which actually tracks the progress of all activities through that chain. I think the final important principle to emphasise is that the control of assets is always the choice of the publisher. A publisher can decide whether they want their data to be free and open data so anyone in the world can see it or whether they want to keep it private and they only want to enable other people to send them a query or something which they will then answer. So in some cases, you want the data to be spread far and wide. In some cases, you want to keep the data yourself and let other people send the algorithms to you. So I think we're a bit like Lander Calculus. The data assets are like values and the algorithms are like functions and it's up to the people building solutions in Ocean to figure out how to assemble them together into something that works for them. So anyway, that's an introduction to Ocean and what we're doing and what we're building. I guess I'll just transition into the interesting part which is to talk about what we're building in closure and I'll show some of the code and how some of that works. So we're using closure to build the core of our reference marketplace implementation. So I talked about having data marketplaces which can allow people to trade data. We're using closure for the back end of that component which is a really, really critical component that's effectively where the buyers and sellers come together to trade, to list assets and to discover assets. So you can imagine a lot of functionality is getting built into this. So we use closure for that. The blockchain itself uses a language called Solidity if anyone's come across that. The front end uses JavaScript. Some of the service providers use Python. Some of the service providers use closure. We've got a really polyglot set of languages in use. But that's actually a strength because we're not trying to build a single stack. We're trying to build a protocol where different components can interoperate. So it's actually really helpful to test out different languages and make sure that the ecosystem is interoperable on that basis. Yeah, there shouldn't be any dependency on having a particular language. Okay, so I'll switch into some code. So I think a few things I wanted to show and I think the easiest way to do is actually to... So what I've done is I've just run this already. I've got basically an HTTP kit web server running locally. And that's serving up a few pages. I'll just show you what it's serving. So this is the back end. So I can maybe show some... I've got some time. I'll show the front end later. But what's interesting is we have this swagger UI, where we basically list all the API endpoints. Anyone seen the swagger UI stuff before? You're familiar with it. Okay. Can we move the machine moves? Yeah, that's the one. Yeah, okay. So this is your standard swagger API. If I want to find out what metadata exists on the server at the moment, I've got all of these different metadata assets. So these are the IDs for the assets. If I want to see the metadata for that one, for example, it's probably a test asset. Yeah, it's a test asset. So basically it's a fully functioning API that basically allows you to any client. So the client could either be a web application, or it could be someone using like programming tools and like just doing remote requests to the API. It's got a bunch of different features. So there's a storage subset of the API. I can't remember if this asset has anything stored against it. Yes, it did. Okay. So it's got a file associated with that asset that I can download. So an asset could be it could be anything in any data, but an asset is most likely to be a data set of some form. So it could be like a big CSV file, or it could be a image file. It could be a video. It's HTTP. It's like you've got a MIME content type, and you can basically put any blob of bytes with a content type you like as an asset. Obviously then, depending on the consumer, they'd have to interpret that asset. But things like CSV would be common. So anything can be basically stored as an asset. The assets all have metadata which describe them, and the metadata can include things like provenance, how that asset was created, and you can have like links to sample files or to descriptions or more human readable interfaces, which is just more convenient stuff for the user. But the core is basically an asset has an ID, and it has a blob of data associated with that ID, and that has a cryptographic hash so that you can validate that the actual data is what you expected. That ID can also be stored on the blockchain so that you can actually validate this metadata, describe this asset which then had this cryptographic hash, and then validate the data. So everything can actually be validated and traced back through effectively cryptographic hash functions. So it's like a tree. It's almost like git. Yeah, we have a tree and the hash of the head determines all of the things that are stored within the asset. Has anyone used Composure API before? Okay, couple. So this is basically using Composure API. So apologies for people who have seen this before, but it's quite a nice still bit of closure magic. So it's a bit like, it's a bit, it's a variant of Composure, if anyone's used that, but it automatically does a lot of stuff for you, like translating JSON, like setting up parameters, and most importantly it creates the swagger files for you. So I've got this particular one set up so that if I want to, what am I doing? I'm just going to hack the storage API very quickly. If I want to create a new endpoint. So this is ring. So it's basically a ring response. So has everyone used ring a bit? A little bit. Okay, so it's just a standard ring stuff. And if I oops, didn't hit us. Okay, so all I did is I hit reload. Yeah, so it's just reloaded this, this namespace. And if I go to the swagger UI, assuming everything's worked. Yeah, okay, I've got a new, I've got a new new endpoint. So this is amazing workflow for when you're actually developing the API, and you're, you're debugging, and you're just trying to test things. You know, I'm not restarting anything. I'm not having to rebuild the server. I didn't even stop the server. Yeah, so the server, I just got an atom that basically, a bar, in fact, where you switch over the old version of the handler for the new version of the handler. And it's effectively atomic. And that's you're then running. So all I reloaded was this namespace. So I've actually, when one of my principles when I'm coding closure is always to write things in a way that a reload does the most useful possible thing. Yeah? Yeah, I'll show you the trick at the bottom. So I basically have so when I hit reload, it's going to reprocess all of this. So this set of routes is basically creating the composure, the composure routes that includes creating all of the web, web routes than the API routes, any middleware. So there's the usual core stuff. And somewhere in here it's got the the swagger generation piece. Forget where it is now. Yeah, swagger routes. So you tell it where you want the swagger stuff to be inserted in the routes. So when you hit reload on this particular namespace, it just rebuilds the whole thing from the top to the bottom and redefines app. Now app is getting referenced in So I'm just going to have to find this. There we are. So I'm using system. So Stuart Sierra's component library is actually a super simple system. I'm only really using it for the web serve at the moment. I might use it for the database going forward, but web serve is fine. And you give it a handler function. So this is a complete hack. You basically wrap it in a function so that when you reload the namespace, app gets to use the new version. Yeah, it's an ugly hack, but it works. So you should be able, if you just put surfer.handler app there rather than the closure, it wouldn't reload. You'd have to reload both. But then this is a system, so you don't want the system to be restarting when you reload the namespace. So that's just a hack to make sure it goes through the function of the cup. So this kind of stuff, I try and keep hidden away from the logic of the code. This is like the nasty stuff that like, don't touch this. If you touch this, everything's going to break. So it's part of your application code that you're working on. So if I want to take that out for my production, if I want to package it for my production, do I tick it off? So I have a really simple way of packaging for production on this one, which is I just have a main class, which starts the system. It's literally that, yeah, it's just basically starting the web server. And because all the dependencies go through the namespaces, that does all of the setup of the handlers and everything like that. And you can stop it and you can do all the usual system reloaded stuff. But the most useful trick is that sort of indirect look up of the handler so that you can basically reload this namespace and have sort of instant refresh. So it will be packaged together a lot more. Yeah, so basically you can package the whole thing, you can do a... Or maybe the question I asked is usually you have things like this that you on the fly changes, then probably the system will behave slower. So when you do a production, it's just going to be like this. Yeah, the overhead of this is so tiny. So I mean, if you think about a web request, you know, if you maybe maybe you're handling 5000 web requests a second or something, yeah, something like that, the overhead of a function call in closure. So like this is I think about 10 nanoseconds. It's of that order. Yeah, it's just completely negligible. And the nice thing is when I do that reload, all of the handler is getting recompiled. It's not like you're interpreting it, it's basically compiling a new version of that of that of that handler and creating the swagger. I mean, you can see how fast it is. Yeah, I mean, it's like this is as we compile it. Oops, go watch the bottom bit and see how long it takes for the app to come up again. Go, yeah, per second. Yeah, so that's what it takes to compile the all all of the handlers is called once once per request, about 10, 10 nanoseconds overhead. I mean, it's about it's probably less, less, less time than converting a number to a string or vice versa. Yeah, it's like just tiny compared to compared to overhead of passing the Jason is just you can ignore it. Jason parsing is in fact probably the biggest cost in this entire system. Maybe database, but that's been pretty fast so far. So, yeah, so it's a nice it's a nice setup basically using composure API and all of this to to develop that. I'll just very quickly, I'm conscious I'm probably running over time, but if I just this is yeah, so we have we have also a front end. This is a JavaScript front end. It's basically talking to exactly that those same API's. What's great about this is that we can open source to two separately. And if people want to customize the front end, customize the bowser, the marketplace, the way that people interact with it, they can do that independent of all the back end API's. So we're trying to keep this very clear division of responsibilities in this in the system. But you can see we've got a whole bunch of different different bits of data which have been uploaded. M or a data. And you know, it describes the data. I don't think there's any sample on that one. It will be yes. So we're still in development. The network will actually go live in March next year. Yep. So you can't do anything with tokens or anything like that yet. But we're getting pretty close to being able to for free open data to be able to like one a marketplace. Well, I mean, it all goes. It would all normally be encrypted. I mean, open data, obviously, you don't you don't care. But yes, it could. It would normally we'd normally expect people to encrypt their data. So so my question is through the ledger. Is it is going to be supported out of the box where I put some encrypted data and then I only share the key for a particular participle? This one is useful. Yeah. So I think the important thing about the the blockchain is all of the current blockchain technologies have the issue that they're not very fast. In fact, they're painfully slow. Yeah. So the amount of the challenge of doing any serious data applications on the blockchain is just currently not feasible. So our solution is to say, OK, we're going to have the decentralized keeper network, which is basically tracking what happens. Yeah. So it's just saying this transaction happened. This asset was traded, but it's not storing the asset data itself, because that would be too large. It would be too cumbersome. You know, you wouldn't be able to afford putting it out on the on the whole network. So the keeper network is tracking the provenance, tracking the transactions, but it doesn't actually see the actual data. The actual data gets stored in these agents, which are playing different worlds in the ecosystem, which is why getting these APIs is really important because that's how these agents interact with each with each other. So you can all think of the keepers. We're really genuinely using it as a distributed ledger, a public ledger. We're not using it for actual data processing or data storage. Yeah. We thought about it, but we came to the conclusion that that wasn't wasn't feasible using current blockchain technology. So can more than one agent provide the same data or the same file? Yes. Yes. Providing the publishers permitted them to. Yeah. And one goes down it will automatically find the other problem? That is a very interesting question that would actually depend on the client. So if the client knows where alternatives to search for, then it could. But we're trying to avoid creating sort of a central single central point of failure when it comes to the database. Yeah. So we're probably not going to try and list every single asset provider relationship in a single place. So those relationships won't be on the keep anymore? Some of them may be, but it won't be mandatory. Yeah. So it would be possible that some of those get stored in the market. The marketplace plays a key role here. Yeah. The marketplace is during the listings of the assets, what assets are available and who's providing them. Yeah. So the use case we're expecting to be most common is that people pick a marketplace, search a marketplace. They can maybe use multiple marketplaces if they want to, but the marketplace will be like the go to place for like your directory of available assets. So it's not a decentralized market? Um, what do you mean by decentralized? I mean, the whole network doesn't know about every asset. The whole network. We have to go to a specific marketplace to search for a specific asset. Is that true? Um, it depends. In fact, on what the marketplaces want to do. So marketplace could easily index other marketplaces. Yeah. So you could see someone saying, okay, I'm going to be like a Google of marketplaces and I'm just going to index them and I'm going to record what assets are in each place. But that index doesn't live on the graph? It doesn't have to live on the blockchain. I mean, you could, you probably could. Only the participants like marketplace as a participant people and consumers and producers and participants. It's just an economic ecosystem. Yeah. So the blockchain really is for the identity of the actors. So who's there? Yeah. Where are my endpoints? I've got to actually be able to find one of these agents that I want to talk to. So blockchain is used for a directory of agents effectively. And it's also used for transactions. So if I buy an asset, some of my tokens go into a scroll until the service provider delivers me an access token for the asset, and then they get the tokens once they've delivered it. And you can do more sophisticated things like you can have dispute resolution procedures in the smart contracts if you want, yeah, like, and you can also have cryptographic proofs. So sometimes you might want a cryptographic proof of delivery or this kind of thing. So there's a few different. It's actually very flexible. There's a cool article about it, service execution agreements. And basically you can create a little graph of conditions that need to be met for a service to be executed. It's pretty flexible, in fact. So you could almost design different workflows for different kinds of services to be provided. And that's on-chain because it has to be because in order to actually do the token transaction and in order to make sure that the payment only gets released at the right time once all the conditions have been met, it has to be on-chain. So those are the main things that, you know, absolutely must be on-chain in order to make the whole system work. So it's a public chain. So the thing about a public chain is any token transaction would be visible. Yeah. Although you may be pseudonymous. So you don't have to tell anyone else your accounts. Yeah. So it's just like a... We just say that who I buy from. I say anonymous A buy from company A. They're anonymous A buy from company B. Then you know there's some transaction for company A. It'll be anonymous A bought from anonymous B using this agent. And if that agent is also not reading any information about itself, it's a pretty anonymous transaction. But producer cannot be anonymous, right? How do we not cannot be anonymous? I mean technically can be anonymous, but if I am a producer of data, I would rather... Probably, yes. Yeah. Probably. So the most common case is a publisher is going to want their metadata to be public because basically people discover it. It's like being on Google. Yeah. You want Google to index your search page so that you can get more customers. Yeah. It's going to be exactly the same with data marketplaces. Most of the time publishers want people to know about their assets. They want people to see their assets. They want their people to search for their assets. There may be a few cases where people say I'm doing a private internal data transfer between trusted parties or within my company. And I'm quite happy for that to be anonymous. So some people will want that. But most of the time if it's like trading an asset or trying to sell an asset, it would be publicly visible. Yeah. Will it support a trading off blockchain network where you are familiar with it? Yeah. So to be determined I think. So for the main... We are currently going with a parity network, a parity-based network. There may be some options to do that in the future. Is it tied to one specific blockchain implementation? Or can you hook it into something else? Is it open to the standard? Yeah. So we are building the version one using a parity-based network, so a parity EVM. So it's using slidderties like effectively Ethereum, Ethereum virtual machine, but the parity network, the parity technology has some cool features that give us some extra capabilities. So could it in the future evolve to use different blockchain networks or different substrates or even run completely off-chain? Yes, absolutely could. So obviously different parts of the stack would have to be modified to account for that. But yeah, you could link it with other networks or you could... There's nothing to stop a marketplace ultimately integrating some kind of payment provider and doing normal currency payments as well. Obviously that you lose some of the cryptographic guarantees when you do that, but maybe that's more convenient for certain kinds of users. So we're trying to build the protocol like the HTTP and then it's open for people to innovate on how they use it and what kind of solutions they build on top. You mentioned identity is quite important, obviously, like verification. How do you ensure that someone's physical identity matches their individual identity as that? Like to provide identity provider? Do you have to copy someone's digital signature and say I trust this key? I think it's one of these cases where there's levels of trust. So we actually allow someone to use the network with nothing but a public key or the equivalent of a theorem account, which is effectively a public key. So you're effectively pseudonymous using a key like that and that's enough to be able to transact. So you can transact on the network providing you can sign transactions and you can have an account and you can move motion tokens into it. So it supports that sort of anonymous usage, but obviously for some of the more trusted use cases, like you could imagine a marketplace for clinical researchers saying unless you are a qualified medical researcher at a registered institution, we're not going to let you into the marketplace and you're not going to be able to buy any of the assets on this marketplace. Obviously that would require real world identity checks and verification. So if it would do that with a bit like Dexter or someone with a root certificate, do the check and sign verify accounts? That would typically be a marketplace operator because we imagine different marketplaces having very different wills. So a healthcare marketplace in the EU is going to have very different rules from, let's say, a finance data marketplace operating in Thailand. They're just going to be very different. They have different rules about who can join. They're going to have different rules about what terms and conditions need to apply, etc. So we imagine the marketplace operators effectively defining the policies and protocols for stuff like verification of identity, if they need it. Now we'd obviously say the rule of identity is you should only demand as much identity information as is strictly necessary. Now a technical question, do you have marketplace agreements? Are people building marketplace? Yes, well, in progress, the network obviously isn't live yet, but there are plenty of people wanting to build marketplaces. Yes, it's a reasonable size job. We're trying to make it easy by building a nice closure reference implementation that then people can take that and customise it. So the plan is that if they want to give it a different look, if they want to change the access rules, it will require configuration. But it's one of the beauties of closure. Everything's data driven. There's just going to be a big edin map where you can say, okay, I want to turn this option on, this option off, and you can let people actually make the decisions on how they want to operate and run their marketplace. So stuff like, is it open to the public? Simple question. That should be a two or false somewhere in a configuration file. And that kind of thing I think we can make relatively flexible for marketplace operators. Obviously if they want to do something completely new and different, they'll have to actually go and make code changes. But a lot of the common requirements I think can be met through like config files. If it's good, yeah, why not? It's open source, yeah? So it's all Apache 2 license. So obviously we think people will create improvements. Some of those will go back into the main line. Maybe someone will create a better version. Maybe someone's going to do something better in Haskell, I don't know. That's the great thing about having a standard protocol people can innovate around the different possible implementations and the different possible use cases. Because sometimes standard protocol, you allow people to change to suit their needs so that you can use various places. So at some point the change is so specific to a group of companies, maybe two or three guys, that they have their own set of standards. They're based on the ocean protocol, but they have additional views that are not compatible with the other guys that are using it. In the end of the day, they look like it, but it's not it. So it's hard to so-called standardize protocol by the end of the day. It's a piece of it that people have different tags and stuff like that. Then back to the web browser days, you have different tags and stuff. Then it's like a standard but not a standard. So how do you actually govern that? I think, I mean, I'm not saying we've got it perfect yet, but we're trying to be very specific about which things are required versus where in the protocol is it open for extension. So for example, in the metadata describing an asset, there's an additional information section where people can put whatever they want. It's like arbitrary JSON. They can just put a big map of properties, and we're not prescribing any of that. Different parts of the ecosystem may decide, hey, we're going to put color as one of those properties and for some reason color is an important property in their field. Fine. We can't actually predict all the possible metadata or all the possible tags that people might want to apply. So we've tried to make sure there's flexibility built into the protocol in appropriate areas so people can define their own sort of variants, if you like. But that's still compatible with the standard. That's still compatible with the protocol. So the protocol just says unspecified, and then it's up to people to decide how they want to use it. And obviously, if people use the same standard, then they'll be able to merge each other's data and read it. But then that will be something which a sort of sub-community would coordinate on or not coordinate on. If it's valuable, people will probably coordinate. My last question. How is your company going to monetize it? Good question. So first of all, Ocean Foundation is a non-profit and it's got a mission to basically create a protocol, open source protocol that everyone can use. The development of the protocol has been funded by pre-sale of tokens. So effectively raise money through pre-selling a chunk of ocean tokens to fund the work that DEX and Big Chain are doing, building the ocean network and the protocol and the various different reference implementations. So that's to get it started. The Ocean Project Foundation obviously continues in its sort of governance role. In DEX specifically, I think we would see ourselves as becoming, I think, probably something more like a red hat model. So professional open source, where we help organizations make the most of the protocol, build solutions on top of the protocol, maybe do a marketplace operator, let's say a government wants to operate a marketplace, but maybe hasn't got the skills to do a lot of complex customizations in-house, we'll say, okay, we can help you with that. Yeah, so it's professional open source model effectively. It's as youthful as you are. Yeah. Nice. Tokens are a fixed pool or? Fixed pool. Yeah, so there's 1.14 billion ocean tokens, which is, I'm told reliably, that's the number of cubic kilometres of meter in the oceans, of water in the oceans. Stupid fact.