 So good afternoon. Thanks, everyone, for coming out. I know it's after lunch, so this is a good one to snooze through if you're really sleepy, like me. Just to validate that I'm in the right room, this is what everyone's expecting to see, right? I have had people that have said no, and I've had to walk out myself. Just to introduce myself quickly, I'm Glenn Boud, and I'm the chief technologist from Hewlett Packard Enterprises, cloud consultancy group in Amir, which means I get to play a lot with OpenStack and OpenCloud projects. The interesting part for me from that is not necessarily just the underlying cloud technology, but the use cases people see on top of it. There's some extremely interesting stuff going on in all sorts of areas. And blockchain is one of those that I found that's a little understood, but can provide a lot of business value if you leverage your technology properly and know what it is. So the idea about this presentation is really to describe what blockchain is and how it gets used in the business. The most famous example being Bitcoin, right? So we'll talk a little bit about that. A bit about the architecture of what blockchain is, the components that make up blockchain and how they fit together, and then how we can provide blockchain as a service. So we'll find that OpenStack lends itself very nicely to this. And there's a couple of organizations already that are taking advantage of the fact that some of this stuff is pretty much half built by the time you get your clusters up. And then we'll look at blockchain in OpenStack. And what I mean by that is how can we use blockchain to solve problems that OpenStack itself has? Is there any way we can apply it and make use of OpenStack itself? So the first one is blockchain. That's Bitcoin, right? So who here thinks blockchain is Bitcoin? Good, nobody. That's the first time that's happened. But maybe it's the way I phrase the question, right? So no, it obviously isn't. What it is is it's a major component of Bitcoin, but it's not Bitcoin itself. And I've seen presentations given by very prominent people in this field at some very prominent conferences that use the words interchangeably. That is incorrect. They are not one and the same thing. So if we look at the kind of architecture, Bitcoin is much more than just blockchain. But blockchain is the fundamental architecture that enables it and all of the other virtual currencies. But we'll go on to have a look at how it stretches beyond just the financials as well, right? It doesn't just play in the currency market. It's enabling all sorts of other things as well. So if you thought this was a presentation, how to come in and make your open stack cluster, make you millions in Bitcoins, I'm sorry, it's not that. But having said that, I do want to talk about the Bitcoin architecture, because it's usually the easiest way to explain what blockchain is, where it fits in, and the components that were in it. So we'll walk through a kind of Bitcoin transaction, if you like, to see what happens. We've got our user here, and she sat at the cafe so she wants to pay for the coffee, and naturally she wants to use Bitcoin to do that. So this is person A. They have a Bitcoin wallet software on their PC, or it could be on their phone, or maybe even the watch, I didn't check, or they can be using the website to do that. But what a wallet is, essentially, is it's a Bitcoin address. So this is a unique identifying address that identifies that individual's wallet. And that identifies sort of, that contains their currency, so like the wallet in your pocket. They have access to that wallet because they have a private key. So the wallet itself is addressed by a public key, which you share with everybody that you want to send you the money. And then you have a private key that allows you to access it. There was a video recently when a news organization in the US was trying to explain to people what Bitcoin and the new virtual currencies were, whereby live on air they showed somebody doing a key exchange. So they advertised the public key by holding up the card, and then they opened it up and showed everybody the private key. And immediately had $2,000 stolen from them. Don't do that. If you have a private key, it's called private for a reason. They did have to explain in the, apparently there was a segment the following day on the same news program that says, don't do what we just did. Fortune was a fairly honest guy who did it. He called them up and said, I've just stolen $2,000 from you because you were silly. And they told him to keep the money, but it was a lesson well learned. Keep it private. So when you're making a transaction, Press and I will use the software they have, so their wallet software, to initiate a money transfer to another wallet, so in this case, Press and B. This creates a transaction. And the transaction has a number of components to it from their perspective. So firstly, it contains their own Bitcoin address, right? The source address, a bit like MAC addressing when you're doing kind of IP traffic. It also contains the Bitcoin address of the person they want to send the money to, obviously. Otherwise, how do you know where it's to go? And it will contain the amount they want to transfer. This gets transformed a little bit in the next stage. So the transaction itself is sent to the blockchain network. And the blockchain network is a collection of devices that are all participating in the blockchain ledger, if you like. The address of the person A is validated, as is the transaction they've just submitted to make sure that it makes sense. There's a digital signature attached to that so they can prove who that person is. The transaction now has multiple parts. It gets transformed a little bit. It has a debit, so it says how much money is going to come from Press and A's Bitcoin wallet. It has a credit. How much is going to person B? Those two values aren't usually the same thing, because there's also a part C, which is a transaction fee. This is how the Bitcoin, like, rock mountain and places like that, that's how they make their money. They take a little bit of money out. So person A is losing more than person B is gaining in this. It's essentially double entry bookkeeping. So for any accountants in the room, and I'm not entirely sure there will be any, but it's essentially that. It's double entry bookkeeping. You record how much is coming and how much is going. This transaction is then a block. So this can become a block on its own. You can also have multiple transactions in this. And we'll look a little bit later as to how that happens. But let's assume that we'll keep it simple and say it's one transaction within that block at the moment. So that block has now hit the blockchain. So thanks to marketing for some animation. The transaction is then propagated to all nodes in the cluster. So every node that's participating in that blockchain will receive a copy of this transaction, which advertises to everybody. They then mine it. So what that means is they'll receive a copy of that transaction. And they have to do some work to prove that that transaction is valid. In Bitcoin terms, it's called a proof of work. There are other ways of doing that as well outside of just Bitcoin. And what the proof of work essentially does is it checks that the transaction up until that point is correct. We'll look at how that happens from a kind of hashing perspective in a moment. But the point is that there's essentially a computational puzzle that needs to be solved. And so you have to put some effort, processing power effort into actually validating that transaction is valid and producing what they call a proof of work. Once a node has solved that problem, they advertise the solution and that node to the rest of the cluster. So the first one that wins, the first one that gets it, will send it out. There'll be a checksum attached to that as well. The other nodes in the cluster will validate that checksum against the rest of the packet to make sure that the solution makes sense. Once validated, you also get a hash. And that hash is the hash of the contents of that block. That hash is then used to seed the next block. So the header of the following block will contain that hash as well. The ownership of the block is then transferred to the new person and they magically get the money and run off with a briefcase full of it, as you can see. The transaction then is also recorded permanently in the ledger. So it's immutable at that point. So to sum it up, the blockchain part of this story is the transaction ledger itself. It's the record of accounts, if you like, that's maintained. It's architected to be transparent, resilient, and trusted. And what that means is that everybody can see what's going on within the blockchain at any one point in time. It's not something that's secret. You don't hide this away. The idea is is it provides body of evidence. It provides proof that these transactions have happened and know the transaction should be secret within that. And it can't be, because as I said, the way you prove that a node exists and the way you compute it is you have to hash the previous block, which means you have no access to the previous block. It appears to appear so that all the nodes participating in the architecture have to talk directly to each other. It's not they're talking to a centralized service. And it allows smart contract, which is the kind of generic name, if you like. In this case, it's the Bitcoin wallet to actually register the transaction. So it's the landing point of the transactions. It's an in-order ledger as well. And that's key to how we became successful. Because you create a hash of the block that's been successful and then pass that hash on to the next one, it becomes impossible to change that without ruining the rest of the chain. So it's been tried. Bitcoin has been, there's lots of people that would like to break Bitcoin and make their own millions. But what happens is because you have such a large network of nodes, changing one means that you'll be advertising the wrong answer to every other node, which will validate that. You become, at this point, a dishonest node. And dishonest nodes get ignored. So once you've been proven that you're sending false information out, you're ignored by the rest of the nodes. Your address is flagged, and you don't receive any updates anymore. The changing of a block means that not only do you break the next block in a sequence because it's hashed, but because the hash of your block is in their header, if you change that block, too, you have to change every subsequent block that's happened in that time period between the block you changed and now. And that's constantly being updated. It's constantly being refreshed by every other node in the grid. So it becomes almost impossible to try and change things. In fact, it's statistically impossible. So this is a kind of simplified blockchain, if you like. They're a little bit more complicated than this. But the header is created of a head of the previous block and what they call the MarkleRoot. And the MarkleRoot is, again, a kind of hash or the source of a group of transactions. So if you look here, we have the block one of transactions. And they're all contained in a MarkleTree. So that's almost a key pair of tree, if you like, that sits underneath. But it all comes up into a root. And the root is the address where you find the rest of the tree. And then you can see that the block one's headed gets passed on to block two. Block two's headed gets passed on to block three and so on. So this is how it becomes immutable. This is how you protect it. But the interesting thing as well is, as I said, you don't have to have just financial transactions in here, right? This can be anything. So the MarkleRoot is key pairs of data. So in this case, we're storing transaction data in terms of money away, money in, and the addresses of to and from. But it doesn't have to be that. And we'll look at some of the other use cases in a minute. So I talked a bit about the proof of work. That's an example of what they call a decentralized consensus mechanism. And we'll look at the architectures in a couple of slides time of how blockchain components fit together and the overall architecture of it. But there's multiple examples of this. So proof of work is one way of doing it. As I said, it validates via a calculation that the transactions have been successful. It's also used to discourage attacker nodes, because it means they have to do a huge amount of work in order to compromise the integrity of everything beyond it. One node would have to do the work of the sum of all of the other nodes plus more over the time period they've had to compute. So when I say discourage, it's a fairly substantive discouragement. It also means that no single one node is in control. No one has the only right story. Every node should be aware of the correct process. So we'll flip into architecture. So it's a decentralized ledger network. So what we're typically used to seeing is kind of the centralized approach, where we have a single ledger, and it sits on one node, and then we have a lot of clients that come in and connect to that node. That's been the traditional banking architecture for a very long time now. And I've worked in a number of investment banks where that's been the case, which means you have to very much protect that one node. But it's also a point that can be compromised fairly easily, right? If you get access to that node and you get access to that ledger, you can change things in there without anybody checking your homework. So that's a fairly inefficient one, because you have to protect it with clusters and all the rest of it. But it's also a fairly insecure one, because it gives you a single source that you can go and edit. The other one is a distributed ledger network, where you have a copy of the ledger sitting on all of the nodes. And this is the same ledger that goes across each node. But you have to then have a checksumming capability where each node will pass on the data to the following node and so on. So they all have to maintain exactly the same data and be updated almost synchronously. When we get to what we're using with blockchain, it's a decentralized ledger network. And you can see it's a group of essentially temporary computers can do this. You don't need them to stick around. They can come in, participate, and disappear again, and then come back in at a later date. But the journal is held on each one of those nodes. And it's updated in usually around 10 to 15 seconds is the kind of lag time you expect to see on the nodes. But it doesn't have to be sort of synchronous replication between all of those. And as I said, a node can disappear, and it won't ruin the algorithm. It won't take away any consistency of what's left. Which means it's not only highly available, it's highly performant, because you can then queue the transaction on any of those. And each one can select a transaction to work on and return the right result. So there's a project called the Open Standard for the Distributed Ledger. IBM are big in this at the moment, actually. You can probably go and see the demo that they have on this on there. They're stand at the moment. And they've come up with an architecture of the components they think are needed for this blockchain architecture to be successful. So the first is membership. So we talked about the Bitcoin addresses for person A and person B, right? What they are is a proof that you're a member of this network, that you are participating in this ledger. So you need a way of doing that. You need a way of a customer coming in and registering, and you need a way of them proving their identity. In Bitcoin, it was the public-private key that news organizations like to advertise. There are other mechanisms of doing that as well. You can do it with certificates. You can do it just by challenge and response. The other part of this is auditability. You need to be able to prove who has done what. Not necessarily to have Bitcoin or blockchain work, but in order to be able to prove to other organizations that it's trusted, that your operations were what you said they were. Everything that happens gets passed along an event stream, so the event stream is shared across all of the blocks of the architecture. Blockchain lives in the middle. And there's four components to a blockchain that kind of manage the transactions, if you like. So there's a consensus manager. And the responsibility of the consensus manager is not to check that the consensus is right. It's to provide the algorithm that everybody needs to use to make a consensus. It's the bit that reports back and says, this is what we're using as proof today. And it can change. It doesn't have to be the same algorithm every day. The algorithm can change as and when you like. It's the consensus manager's job to distribute that algorithm. This is how nodes can join and leave as they want, because they report back into the blockchain. And the blockchain consensus manager will tell them what it is they need to do, what work needs to be done in order to prove the transactions. Obviously, there's a distributed ledger part. You need somewhere to store all of this stuff. So this is the actual book it gets written down in, if you like. And that sits on ledger storage, so that usually, in most of the architectures I've worked with, it's local disk on the nodes themselves. And that gets distributed between all of the nodes. And then there's the P2P protocol. So Bitcoin has a specific one, but any blockchain can use, running it describes its P2P protocol in an open standard. That can be the one that gets used. Nobody's dictating that. The last thing is chain code. And what chain code is, is the actual container, if you like, so the wallet in this case, is what we call chain code. But it could be anything. It's the thing that produces the transactions at the end of the day. It's important to have secure chain code. So it's important that you're all using the same, everyone that's participating in those transactions, are using the same sort of chain code, the same version chain code, so that the transactions can be validated properly. The risk of using bad chain code is not that you'll pollute the rest of the ledger. It's that none of your transactions will be accepted and they'll be rejected because you're either sending something that's insolvable in which case you'll get rejected because no one can solve your problem, or you'll be identified as a dishonest player and removed from the cluster. And finally, there's a secure registry, which is where you'll need to keep that kind of trusted chain code, if you like, so that it can be distributed to those nodes. So in terms of the components you need to do that, the first one is DNS. When a node first joins a blockchain, what it'll do is it'll query the DNS for a seed node and the rest of the nodes that are in the chain. And the seed node isn't anything special. It's the first one that gets back from the DNS query. So when it sends a broadcast to the DNS server saying what's the root of my blockchain, it'll get back an answer. And it's around Robin, usually anyway. The other thing is NTP. So time is critical here. If you start getting out of order, you can't get it out of order because of the hashing, but if your time isn't right, you can start getting rejected because you become out of sequence. There are time stamps that stand along with those transactions that are important as well. So NTP is a very good one to have. And then the certificate authority. And this is where you're storing those keys. This is where you can go and get the certificates so that you can initiate those transfers in the first place. When you register, you'll need a certificate of your own, so it'll create a public and private one, and it needs to be trusted. And then there's all the member nodes, and they all have a bunch of storage to go with them as well so that they can actually store the ledges. And they are transient. They can be transient. So the components look fairly cloud native, and it turns out that they're a very good match for kind of OpenStack architecture. There's a lot of projects in OpenStack already that, as I'm going through the requirements on the last slide, there are probably names of projects popping into people's heads in the room. As in, well, we've got a project that does that, and why can't we just leverage that? And the answer is we can, and we've built stuff that does that. The whole nature of the architecture, the whole transient node thing, is perfectly suited to kind of what we're calling cloud native, if you like. It's a buzz phrase I'm not keen on. But it's a model that works well on both OpenStack and containers and everything else. So it's the stateless node that can be transient that works on data that's shared between the clusters. It's a perfect fit, and we've found it very easy to deploy. Also, we've worked with customers that are using heat to deploy these things. So there's a bunch of different services in there, and you can deploy whole blockchains at once by deploying new DNS services, by deploying new certificate authorities, and then by deploying groups of nodes. So it's easy to write heat templates to deploy this stuff, and it's pretty rapid as well. I just want to quickly talk about use cases before I go into the projects, because a lot of people say, well, it's just Bitcoin, right, or my favorite Dogecoin. Why would you, what else can it be useful? There's a ton of different use cases for this, and I don't really have time to go into a huge amount of depth on all of them. But if you want to talk about some of these, then come and find me afterwards. The obvious one is finance, currency, transactions, banks that are doing transactions between themselves and between customers, so a standard kind of financial accounting ledger, and business to business transactions as well. So actually accounting for shares being transacted, not just currency itself, but buying something for a cost, right? So that's all the fairly straightforward ones. Medical and health care is an interesting one as well. You need to share patient records between hospitals if you're in a kind of hospital trust, if you like, so in the UK, we have different NHS trusts up and down the country that all manage to hurt patients in slightly different ways. But they need to share your records between them so that if you move from one location to another, if you're on traveling, then your records are accessible by any of those hospitals. And going to see a hospital, getting drugs administered to you, all those sorts of things are transactions, and you can have records of those transactions held in this distributed ledger that all of the hospitals can participate in. The other is drug trials, and this is an interesting one that we're seeing some interest in, particularly at Geneva at the moment. Drug trials are, you try something, you perform one activity, and then you get a result back. And in order for the drug to be certified so that you can start selling it to people or start providing it from the hospitals that are also using blockchain, I would say, you need to prove that you've done that testing. There's a surprising amount of drugs on the market where the assumption has been that the testing has been done, but in actual fact it hasn't been, or at least it can't be proven. And the reason is it's difficult. It's a hard thing to achieve. And despite the best efforts of some of the pharmaceuticals, it's a challenging one to solve that they can show that the drug tests have been completed and here are the results in a kind of open manner. So there's investigations going on at the moment to see if blockchain centrally can be used, that all of the pharmacies and anyone that, for example, in the USA, I think it's the FDA, is it, the Food and Drug Association Authority, they're looking at having a centralized ledger where everyone has to publish the results to. And then the results can be checked. Remember this proof-of-work concept, where you can provide proof-of-work algorithms that show that the drug tests have been done or that the results that have been published to the ledger are correct. So we're seeing interest in that. That's not there today, but there's a lot of interest in kind of moving it forward. Gaming and gambling we're seeing interesting. And so gambling's again a fairly obvious one. It's a financial transaction, right? You make a bet, you lose, and then your money goes away. I hear some people win as well. So that's one obvious one, because it's a financial transaction. But we're also seeing interest from gaming companies. So massively multiplayer online role-playing games, or MMORPGs, things get bought and sold in them. You can buy armor and weapons and houses and whatever else it is you do in these things. But there's financial transactions of a virtual kind that are going on within these games. And these games are distributed across hundreds of servers across the globe. So blockchain is a perfect way for them to audit those transactions and make sure that nobody's stealing the sort of wonder or whatever it is it's called now. It's a good way of kind of maintaining all of that. The other one, and the ones I'm interested in from a kind of open stack perspective, is firstly, imagine a Git repository that's backed by this. It means you don't have to go to github.com and have a single repository that you must trust. You can distribute that globally. Now, there's some work you need to do in terms of merging and trunking and things like that. But you will have at that point an excessively scalable repository of source code. I'm not suggesting the source code gets contained in the ledger itself, but the ledger will tell you where the blocks live of that source and it'll show you who's committed it. And more importantly, it's in order because of the hashing. So there's an interesting use case that's being examined to see whether it's something like a globally distributed Git repository or a source code repository might work with this. And the other is event logging, which I wanna talk about a little bit when we get to the open stack piece. So, I said there's plenty of projects that are in open stack at the moment that enable some of this. And I mean, you don't have to build so many different components in order to get it stood up. So the first one is identity, proving who you are. Well, we can do that already with Keystone. Keystone is our identity manager. It maps roles. It maps metadata to users, all those good stuff. So that's already there. The certificate authority management, we have Barbican. So that can manage our keys. It can manage our distribution of those keys to the nodes and it can be somewhere where you subscribe to go and get some people's public keys and can provide directory services in that sense. Node management, so just actually standing up the blockchain nodes, I said they're transient. Well, we all know open stacks good at transient. So we can use Nova to do that and the storage can obviously be provided by the Cinder or Swift. So that gives us local storage within those nodes that we can store these ledges on. DNS, we have designate. So we have DNS as a service available to us. So as we create the nodes, we can register it in a centralized DNS service and advertise the fact that nodes exist. The challenge with transient nodes is always getting them into a fixed DNS service. Unless you have something that's a bit dynamic, it can be challenging because it relies on somebody going and updating something somewhere. As I already mentioned, to manage the whole stack of things, if you're standing up multiple services and multiple nodes, we have heat and then there's Murano that you can sit in front of that so you can create catalogs of these things. So the whole idea of blockchain as a service is that somebody can go and subscribe to the service and stand new bits up. And then the chain code binary. So there's a project called Glare which is a kind of binary repository and Glance v3, I think it is, has introduced kind of check summing and signed packages within that. So you can now put your chain code into Glare and have it signed and verify that you've got a valid chain code package before you start executing against it. So in terms of what that looks like is a picture. We can see that we're using Barbican to provide keys and key management. We've got Keystone for the identity, all the bits we just talked about essentially. I've got Kubernetes in there as well because these are perfect environments for deploying into containers. So it doesn't have to be into a VM. Containers work just as well with it, in fact, if not better. And if you look at some of the open source architectures and the open source containers, open source blockchain projects that are going on. So there's open block and open chain and there's a couple of others as well. They provide most of their source code in the form of a container. So you can go to Docker Hub and there's a bunch of blockchain that's already there that's just a Docker container that you can download and deploy on your laptop and start playing with. So finally, I wanna talk a bit about how we can use it to solve open stack problems. And I hinted it a little bit when I started talking about the IT part. Compliance is a big thing I come across. So I do a lot of work with financials and I do a lot of work with governments at all levels. And compliance within the cloud is the big thing they were worried about. It used to be just security because everyone assumed that clouds were insecure. Then we got away with that myth. And now it's compliance. How do you prove that what's going on in that cloud is correct? You've got IT policies such as how patching needs to happen, how servers need to exist, how many customer can have, how do you kind of look after all of that? Well, you need to have a way of mapping those policies onto what's going on in the cloud. So business level policies driving the IT services and their governance. The logic of the compliance policy should determine what exists within an environment. That's the way it always existed and it's usually been manually kind of supported. We need a way of automating that at scale if we're gonna start doing it in a cloud. Enforcement then for should either be able to correct a kind of breach if you like by either applying a patch or removing a node or hopefully it'll prevent it from occurring in the first place. The policy will block it. There's some work going on with NOVA at the moment to add a filter to NOVA so that it goes out and check policy engines before it deploys. Manipulation of components have to be trusted and audited. So the one thing you wanna be able to do is prove that somebody asked for something to happen. If something comes up that's non-compliant then somebody's to blame for that usually. Now it doesn't have to be a bad actor. It could just be that something's gone wrong in the process but you need to be able to find how that non-compliance found its way into the environment and so audit log is a good way of doing that. Compliance is only good if you can demonstrate proof that you're trying to do it. So with the large financial organizations everyone heard of things like 2P and all the other bits and pieces that go around it in PCI. If you get audited it's no good saying we tried our best on this governor because it won't happen. You're still going to prison or getting a fine at that point. You need to be able to prove that you showed steps. You need to be able to show that here's my audit trail of what I did. Here's everything that's happened. We can see it went wrong but we know why it went wrong and or who made it wrong and this is the person that needs arresting. But it's useless without audit, right? You can't have compliance without audit. Blockchain ledgers provide a brilliant way of getting that audit across your cloud. And the reason why I would say there's other mechanisms for having immutable locks but the reason why blockchain is good is because you can distribute it across any environment that you're working in. So it can happen in your private OpenStack cluster and across different data centers. It'll happen on your public cloud if you put it out there. It can happen with your partners and your customers. So this can be distributed to everybody and give you a kind of distributed log of the events that have been happening. And the reason why customers would agree to that is because they also want to know what's been happening because you're billing them for it usually. If this is some kind of charge back mechanism you're using then this is also a way that they can come back and say I didn't ask for this but I'm paying for it or I did ask for this and you never provided it. So there's a project called Congress within OpenStack and it's the policies of service project. So what it is is it provides a kind of structured policy language if you like and there's a good wiki that describes the language and how you can write the policies for it. It's leveraging a lot of other OpenStack projects and not all of them are fully mature yet. So Mistral is one of them but that's actually fairly mature and that provides work flow as a service. So what that does is this is the action I want to take when I trigger a policy event. So either I'm trying to stand something up and I'm validating my policy or my policy has been breached somewhere and I want to take action against it. So Mistral is a good way of defining those workflows and having them executed in a standard way. The one thing that we haven't talked about in Congress yet is that immutable audit trail though. It doesn't exist. Congress is all about enforcing the policy and defining the policy. It's not about auditing whether the policy has gone right or wrong. So what I'm looking at at the moment is ways that we can get blockchain into Congress or have another project support Congress that is based on blockchain. So we can post the audit logs and the event logs and the output from Congress into an immutable log that we can then take action on. And again, this is something that would need to be provided for breaches and when you get those investigations you then have that audit trail you can go back to. And as I said, the transaction log of the resource ordering that's happened when people have logged in or when you've got a computer computer event that's creating nodes or creating new resources, audit them. I had a customer that worked in the HPC space that had a, what they did is they would generate resources based on queue depth. So as the queues for the jobs were coming in, if it went past a certain point it would stand up another node and so forth and so forth. So if you had a very long queue you'd stand up a lot of nodes. And somebody made a change to the code that did that and it stood up everything it could. It just went crazy. It cost them a lot of money because it was on a public cloud that they were trying to do this. And they had to, they were saying, no, no, we didn't ask for this. So they went back to the public cloud provider that presented them with a very large bill and said, no, no, we didn't ask for this. Something went wrong. The public cloud obviously had an audit of everything that was going on and could say actually this machine requested this amount of nodes be created and it did it this many times. You need that within your own kind of private clouds as well to show that what's been requested is actually what's happening. The other place where this is useful and you'll see it a lot in the financial market or I see it a lot in the financial market is if somebody asks for something to be destroyed, particularly a Cinder volume or a Swift container because there could be data in that that's compliant value data and you need to show who said to destroy it in the first place. If it's an email log, for example, maybe a presidential candidate or something, you want to log the fact that it's could potentially be disappearing without permission. What it does, it means you have an enforceable cloud compliant policy that you can prove and demonstrate and that will get you a long way when it comes to the auditing agencies. So in terms of customer billing, as I said, you can only bill for what you can prove as requested. So if you're a provider, you have to be able to show that something was requested. I kind of demonstrated the HPC example. And all that helps both sides though because it's essentially a receipt. You can go back and say, I didn't actually request this and you have to prove that I did and if they don't have the audit turned on, they can't or I requested something, you're billing me for it or you haven't actually provided it. So when you're looking at the transactions that go into the kind of blockchain transaction log, you need to have both sides of that execution, right? A transaction is a request for something and it's a fulfillment of that thing. And it's open and transparent, so everyone can see it. There's no hiding it, it's distributed between all the different systems that you're using and nobody can hide anything within it. And as I said, it can span multiple sites, cloud environments and geographies. So if you've got an organization that has different resources in different locations, you can spread the blockchain architecture between all of those environments. And maybe you can pay with Bitcoin. So we do get back to Bitcoin in the end. So that was all I had. If you have any questions, there's a microphone here, so it's being recorded, so feel free to wander up and ask questions at the mic. Hey. 51% of the mining power. What happens to what, sorry? If I have 51% of the mining power. So we're going back to Bitcoin again a little bit. Can I become the most, can I become the one that validates other nodes in the cluster if I have the most nodes? So every node has to prove you're correct, otherwise they'll reject your block and then you'll end up with, so what happens is, until you've proven one way or the other, you end up with extra depth. And each block has what they call a block depth which shows how far from the beginning it is. And you end up with multiple blocks at that depth. So you need to prove every node needs to accept that you're correct. So if they come in, even if you've got 51%, you'll end up with another chain that starts. But if I have like, let's say there are 100 nodes and I control 51 of them and I control them for a while. So at one point I turn evil. It's still, you'll still end up with the other chains. The other chains won't go away because it's not a majority vote. Oh sweet, have a speed. It has to be, you can solve it with the, I mean if you're evil and you control 51% of the node then you can probably inject the bad code chain in to start with. But it's not a majority vote. You can have 99% of the votes and that one node can still go in and say you're wrong. And then they'll all be marked as bad players because somebody's proved that the sum doesn't add up. Any other questions? Nope, okay cool, thanks very much. I'll be around anyway if anyone does wanna have a chat. Thank you.