1 00:00:00,000 --> 00:00:05,400 Well, over the next couple of episodes, we're going to have some, I don't know, to be blunt, 2 00:00:05,600 --> 00:00:09,320 some promotional effort to get people interested in the Cloud Foundry Summit. 3 00:00:10,000 --> 00:00:14,820 And at the end, I have a little code if you end up wanting to go to get 20% off registration, 4 00:00:15,100 --> 00:00:19,300 if you want to go to that. What we're going to have in these episodes is I'm going to talk to 5 00:00:19,300 --> 00:00:23,160 some people who are speaking at the Cloud Foundry Summit, just giving a little preview 6 00:00:23,160 --> 00:00:27,520 of what they'll be talking about. So why don't you introduce yourself, first guest? 7 00:00:27,520 --> 00:00:31,940 I am Gary White. I'm working with the Dell EMC Dojo in Cambridge, Massachusetts. 8 00:00:32,560 --> 00:00:37,280 And the talk that I'm going to be giving is building blocks of blockchain, 9 00:00:37,840 --> 00:00:42,740 blockchain as a service. And we're going to dive into why you need blockchain, 10 00:00:43,320 --> 00:00:49,140 what is blockchain, and what promoted the idea that you're going to need to use it in the future. 11 00:00:49,480 --> 00:00:55,620 And then from there, I'll give a demo on something that we've implemented running on Cloud Foundry 12 00:00:55,620 --> 00:01:00,080 to give a practical example of how you might use it moving forward. 13 00:01:00,080 --> 00:01:04,160 Yeah, well, this would be great, because I don't really know anything about blockchain or anything. 14 00:01:04,320 --> 00:01:09,740 Let's start with like, to my ignorance of this, like, what exactly is blockchain? 15 00:01:10,120 --> 00:01:17,940 Like, I know the following. There's some sort of cyberpunk named character who's always running around 16 00:01:17,940 --> 00:01:26,200 doing it and ledgers. And there's probably some sort of magic, mysterious math that with a lot of curves 17 00:01:26,200 --> 00:01:29,700 that I don't understand. So that I'm out. That's all I know. 18 00:01:29,840 --> 00:01:39,080 All right. Okay, so we should start. The first thing that you said was that it is a heavy or I think you 19 00:01:39,080 --> 00:01:48,440 said it's just a ledger was the leading point. And that's basically the idea is that we have always 20 00:01:48,440 --> 00:01:55,920 had this distributed system problem of how do you get everybody to agree on something that needs to 21 00:01:55,920 --> 00:02:05,240 happen. So to put it to a bit blockchain example versus a database example, if you can imagine that 22 00:02:05,240 --> 00:02:15,020 there is a MySQL distributed system like Cassandra, where you want to write something into the database. 23 00:02:15,780 --> 00:02:23,080 How this would normally work is there would be a pre-elected leader as a node in a Cassandra 24 00:02:23,080 --> 00:02:29,020 cluster. So maybe four or five and one of them happens to be the leader. You would ask that leader, 25 00:02:29,180 --> 00:02:33,580 hey, I'd like to put this in there. And the leader being the one who's keeping the state of the 26 00:02:33,580 --> 00:02:40,860 database would insert it accordingly to when you posted the request. But a problem with that is 27 00:02:40,860 --> 00:02:46,740 that if I just continually ask to be the leader, I can become the leader and write whatever I want. 28 00:02:48,100 --> 00:02:54,480 And that's kind of where distributed systems start to break down, because it's very difficult to become 29 00:02:54,480 --> 00:03:00,520 false tolerance to situations like that. And I can wax and wane about a few more examples that they 30 00:03:00,520 --> 00:03:09,300 have in lower level systems like flight control and time synchronization. But blockchain is at its base, 31 00:03:10,300 --> 00:03:19,860 a system that is intended to continually provide a verifiable ledger that will make it easier for 32 00:03:19,860 --> 00:03:22,920 data to be synchronized across multiple nodes. 33 00:03:23,720 --> 00:03:29,160 So there's kind of there's kind of like, tell me if I'm wrong or some missing anything, but seems like there's 34 00:03:29,160 --> 00:03:37,280 three main parts. One is it's distributed. And it would be interesting to hear, you know, your explanation of 35 00:03:37,280 --> 00:03:42,060 each of these things when it's and by distributed, it means like you don't just have one machine that controls 36 00:03:42,060 --> 00:03:50,740 everything. And in theory, you sort of you solve or you address kind of like the the the locking problem, a 37 00:03:50,740 --> 00:03:55,880 locking problem being that if you have one piece of data and multiple people want to both read and modify 38 00:03:55,880 --> 00:04:01,580 it, you have to have them wait in line to make sure that they get the right data or write, or write the 39 00:04:01,580 --> 00:04:07,400 new piece of data correctly without screwing it up. I mean, that's my my fanciful way of defining it. And then 40 00:04:07,400 --> 00:04:16,460 the other thing is, it's basically verifiable. This is the part that I think I think I don't really know how that 41 00:04:16,460 --> 00:04:24,260 works. But you can somehow verify that it's accurate, I think, and and then that the the entity or the person 42 00:04:24,260 --> 00:04:31,480 who did something is actually the person they claim to be. I don't know. And then, and then and then I guess the 43 00:04:31,480 --> 00:04:39,020 third thing is the applications of this mean that there is, there is, I mean, I guess I've never thought of it as 44 00:04:39,020 --> 00:04:47,020 sort of like a database, but there's essentially a way to have a a very trusted data source to know that all the data in 45 00:04:47,020 --> 00:04:54,440 it can be relied on to do something. One, because it's it's been verified that the correct people have set that data in 46 00:04:54,440 --> 00:05:00,160 there. So I imagine there's access control or something or maybe not. And then to and then to because it's it's it's it's 47 00:05:00,160 --> 00:05:06,420 distributed, it's a lot easier for many people to use that data set. And rather than just having one person 48 00:05:06,420 --> 00:05:17,520 using it. Absolutely. So in order of those points, I think first one was how do you write where I want 49 00:05:17,520 --> 00:05:23,500 to write something, does that mean that I can just immediately call some endpoint and write it? Or do you 50 00:05:23,500 --> 00:05:30,820 have a distributed system of everybody reports to some central authority and the central authority would 51 00:05:30,820 --> 00:05:39,140 provide the right permissions? So that's, that that's one question where you can either have the 52 00:05:39,140 --> 00:05:44,620 central authority at some level or another, that just lets you do what you need to do as long as they 53 00:05:44,620 --> 00:05:52,540 say it's cool. But if you can compromise the system that says that it's okay for you to write into the 54 00:05:52,540 --> 00:05:58,140 database, then you can write whatever you want. And so that is one of the problems is that you have to 55 00:05:58,140 --> 00:06:03,120 make an assumption that the central authority will always either be available because there will never 56 00:06:03,120 --> 00:06:09,620 be like a DDoS attack, or that it will always have integrity, right? It hasn't been compromised to 57 00:06:09,620 --> 00:06:14,280 absolutely security terms, right? That makes sense. So that's number one is how do you write? 58 00:06:15,220 --> 00:06:21,020 The second one is data integrity, and verification of who and when it was written, 59 00:06:21,580 --> 00:06:29,260 where I want to make sure that all of the data that I've written isn't just going to somehow disappear 60 00:06:29,260 --> 00:06:40,220 without proper process. And who wrote it and who did what when. So I'm going to try to compress this, 61 00:06:40,220 --> 00:06:47,340 so just stop me if I go a little too far. But Bitcoin, for example, does this by using a very clever 62 00:06:47,340 --> 00:06:56,140 hashing algorithm that takes an entire transaction as it's written in a certain form. So that transaction 63 00:06:56,140 --> 00:07:05,420 might just be a string that says a four character identifier sends to another four character identifier, 64 00:07:05,900 --> 00:07:10,700 and then that is followed by an amount. So they know that that's like a 30 byte string or something like 65 00:07:10,700 --> 00:07:18,380 that. They would always hash a 30 byte string, and that would produce a transaction hash, so that you 66 00:07:18,380 --> 00:07:23,260 would know what the transaction looked like. Because then if somebody hands you a transaction hash that 67 00:07:23,260 --> 00:07:30,380 doesn't match the 30 byte string that you provide with it, then you would know that that transaction 68 00:07:30,380 --> 00:07:33,980 string was invalid. Does that make sense so far? 69 00:07:33,980 --> 00:07:39,500 Yeah, yeah. And that way, that way, I mean, removing for the moment the part of verifying 70 00:07:39,500 --> 00:07:44,780 that whoever created that original string that got hashed and inserted into something, let's assume 71 00:07:44,780 --> 00:07:49,580 that was all hunky dory, but per your first point. But then that would mean that, like, 72 00:07:49,580 --> 00:07:54,860 let's say the two entities are like Twitter handles or something. And it would basically be a way of saying 73 00:07:54,860 --> 00:08:02,940 that at one point in time, Person A said that they promised that they would give $5 to Person B. 74 00:08:03,580 --> 00:08:10,540 And we can trust that this actually happened because we have it in this record. And so if I want to go, 75 00:08:10,540 --> 00:08:17,180 and if Person B goes and says, I want to convert, like, I want to get that $5 in cash, the ATM system 76 00:08:17,180 --> 00:08:22,060 can go look at the magic ledger and kind of like, it can, I guess, recreate that hash and verify that 77 00:08:22,060 --> 00:08:27,420 that that actually exists in the ledger of the people. And then therefore, I mean, this gets into the 78 00:08:27,420 --> 00:08:32,460 philosophy of money and how it's all actually kind of like, you know, a giant spreadsheet in the sky of 79 00:08:32,460 --> 00:08:37,660 funniness. But, uh, but essentially it says this thing happened in the past and therefore you can 80 00:08:37,660 --> 00:08:42,540 reliably make decisions like dispensing cash based on it in the present and the future. 81 00:08:43,100 --> 00:08:50,140 Yes. And so that, that, that one piece can then also be scaled to make sure that everything in the 82 00:08:50,140 --> 00:08:57,180 past is still, um, still has the integrity that you expect. So then you can take all of those hashes 83 00:08:57,180 --> 00:09:03,820 that you already have and you can have them hash together and that's called creating a Merkle tree. 84 00:09:04,460 --> 00:09:06,460 Um, that's if you want to get really technical. 85 00:09:06,460 --> 00:09:09,740 Now that's probably named after the German prime minister, right? 86 00:09:10,460 --> 00:09:11,900 Obviously. Most likely. 87 00:09:14,380 --> 00:09:20,860 But they, um, when you create a tree, then all of the hashes that created the tree, if you change 88 00:09:20,860 --> 00:09:27,820 one of the hashes, then the final hash will change. Right. Right. And that verifies the entire, uh, 89 00:09:27,820 --> 00:09:35,740 history of transactions. Absolutely. And then, um, where that like GPU mining comes in, where you 90 00:09:35,740 --> 00:09:42,220 think of the warehouses full of, uh, those warring machines that are trying to find some condition. 91 00:09:42,780 --> 00:09:48,380 Um, I'm just going to make one up. I'm going to say that, uh, for you to write something onto my 92 00:09:48,380 --> 00:09:57,260 blockchain, uh, you have to produce a hash that is starting with zero, zero. And so you can take 93 00:09:57,260 --> 00:10:03,660 that whole transaction hash that we just created by hashing a bunch of transactions together and then 94 00:10:03,660 --> 00:10:11,260 just continually add things to it. Like you can add one more hash value to try to make it satisfy my 95 00:10:11,260 --> 00:10:16,620 condition. So you have a hash value that's like one, two, three, four, five, and it has to start with 96 00:10:16,620 --> 00:10:23,740 two zeros. You would just continually hash it against things that you would just pick out of the ether 97 00:10:24,540 --> 00:10:31,820 and it would eventually satisfy the condition. And when you find that one piece, that one hash that you 98 00:10:31,820 --> 00:10:40,140 can hash together with all of your transactions, that is called a, um, nonce value. And you would, uh, 99 00:10:40,140 --> 00:10:49,020 publish that, uh, signed, uh, signed with your private key along with your transaction ID or your block 100 00:10:49,020 --> 00:10:55,340 ID at that point and the list of transactions that you're verifying. And so that's what you would call 101 00:10:55,340 --> 00:11:03,660 in, um, Bitcoin's vernacular. You would call that proof of work because you could, um, theoretically 102 00:11:04,860 --> 00:11:12,540 guess that nonce value the first time you could be very lucky and satisfy my condition that I've set for 103 00:11:12,540 --> 00:11:18,540 the blockchain by taking that transaction hash and then hashing it with the very first thing that you 104 00:11:18,540 --> 00:11:27,100 guess. And then it works great. But most of the time it's going to take, um, like they have some 105 00:11:27,100 --> 00:11:35,100 mathematical theorem for how long it should take. And based on that theorem, um, they can prove that you 106 00:11:35,100 --> 00:11:41,340 didn't just join the network and start writing whatever you wanted. You most likely are participating 107 00:11:41,340 --> 00:11:48,220 in the network to get a reward for having done that work. And then, and then my sense is that when you get 108 00:11:48,860 --> 00:11:56,700 some nonce you sort of like generated money or something, I don't, and then, but then that gets to my second 109 00:11:56,700 --> 00:12:05,020 question is like, so why is that valuable? Like, like, um, I don't know, is there sort of like a scarcity of 110 00:12:05,020 --> 00:12:10,140 nonces or something? And those are the things you need to generate in order to represent money. So it's sort of like 111 00:12:10,140 --> 00:12:15,580 you're printing money or something. It's not even like, maybe it's not even like you're printing money. It's more like 112 00:12:15,580 --> 00:12:20,380 you're manufacturing the paper that money can be printed on. I don't know, but like, but like, why is 113 00:12:20,380 --> 00:12:25,500 it valuable? So valuable to find a nonce that like it, it equals some money sort of thing. 114 00:12:26,140 --> 00:12:33,820 So that is such a great question. And I am so happy that you just asked it because if you think of what 115 00:12:33,820 --> 00:12:39,740 we talked about with all of those transactions being hashed together, the point of a hashing algorithm 116 00:12:39,740 --> 00:12:44,220 is that it's completely random. You have no idea what's going to come out the other side. 117 00:12:44,940 --> 00:12:51,020 So when you hash all of those transactions, then you're verifying that all of those transactions 118 00:12:51,020 --> 00:13:00,300 are going to be, um, uh, reproducible as the hash that you've provided. So I always know that Gary sent 119 00:13:00,300 --> 00:13:07,260 Mike some amount and that's just in a transaction. And then nodes are going to pick these transactions 120 00:13:07,260 --> 00:13:14,300 out as they are broadcast throughout the network. And they create this tree until their block 121 00:13:14,300 --> 00:13:20,460 is filled with transactions. And they say, Oh, I can't take anymore. So now I'm going to start my 122 00:13:20,460 --> 00:13:26,780 nonce procedure. And the nonce is something that you just, there's like, there's no way to know what it 123 00:13:26,780 --> 00:13:35,740 is because it's just completely impossible to guess it or to do anything, but guess it because that's how 124 00:13:35,740 --> 00:13:40,620 hashing works is you don't know what's going to come out the other side. So when you have this 125 00:13:40,620 --> 00:13:47,820 huge transact, this block of transactions, that's verifiable by that one hash, then you can continue 126 00:13:47,820 --> 00:13:55,580 hashing against that hash to satisfy some value. So I can hash one, two, three, four and five, six, 127 00:13:55,580 --> 00:14:01,580 seven, eight together. And eventually the hash will start with two zeros. And when the hash starts with 128 00:14:01,580 --> 00:14:10,700 two zeros, I have proven that these transactions have existed on my, um, system for a long enough 129 00:14:10,700 --> 00:14:18,540 time that I was able to find that value that, that nonce value that produces the verification that most 130 00:14:18,540 --> 00:14:26,620 nodes have probably seen this transaction. And so when all of those transactions are verified and 131 00:14:26,620 --> 00:14:33,660 I've created the nonce value, I am contributing to the proof that that transaction is valid. 132 00:14:34,700 --> 00:14:41,100 And by contributing to the proof that that is valid, I am doing that through the work of finding the 133 00:14:41,100 --> 00:14:47,100 nonce value. Does, does that make sense where I think so? Yeah. Yeah. So, so basically the value 134 00:14:47,100 --> 00:14:54,380 in like setting up all of these Bitcoin mining things is, uh, you're sort of like contributing 135 00:14:54,380 --> 00:15:02,140 to the overall effort of auditing the validity of everything. And then, and so therefore I assume 136 00:15:02,140 --> 00:15:09,100 people or people systems that use it sort of like pay you some way, like they, you exchange these 137 00:15:09,100 --> 00:15:14,460 nonces that you found in exchange for some form of payment or something, or maybe, maybe the whole 138 00:15:14,460 --> 00:15:18,940 system is written that once you contribute a nonce that it automatically like creates value for you 139 00:15:18,940 --> 00:15:24,140 or, you know, transfers, I'm putting this in air quotes, transfers money to your account or something 140 00:15:24,140 --> 00:15:29,420 like that. Yep. You're exactly right. Because when you transfer that nonce out and you say, 141 00:15:29,420 --> 00:15:35,740 hello everybody, I found a block. Then you can sign that block with your private key. So everybody 142 00:15:35,740 --> 00:15:43,020 knows it was you and everybody will agree that there is a transaction now that just randomly 143 00:15:43,020 --> 00:15:51,180 awards you 25 coins. Okay. Uh, Bitcoin started with 25 and then, um, for reasons of inflation and 144 00:15:51,180 --> 00:16:01,420 economics, they, um, they decrease it by half. I think it's every 210,000 coins. Um, 145 00:16:01,420 --> 00:16:07,260 they, they reduce the effort, um, or they reduce the value by half. 146 00:16:07,900 --> 00:16:11,980 So, so then, so then, so then to try to round out the Bitcoin part, because Bitcoin is, is like, 147 00:16:11,980 --> 00:16:16,460 I mean, it's fascinating, but to the point of, of, of your talk, I believe there's all sorts of other 148 00:16:16,460 --> 00:16:21,020 things to do with blockchain, but tell me if I've got this right. So in, in the Bitcoin world, 149 00:16:21,020 --> 00:16:26,300 so first of all, there's various types of Bitcoins, right? They got the, the BitBitcoin and the Dogecoin. 150 00:16:26,300 --> 00:16:30,540 And, and I think ours, Technica has its own coins. Now those are like separate currencies, 151 00:16:30,540 --> 00:16:34,620 right? Or are they, are they related? So you've got these separate currency systems 152 00:16:35,180 --> 00:16:39,500 and theoretically there's a set of norms. Whoever participates in these, these, uh, 153 00:16:39,500 --> 00:16:45,740 Bitcoin currency markets, they're like, they basically say, if it is verified that you own 154 00:16:45,740 --> 00:16:51,180 this nonce, whether you generated it or it's verified that someone gave it to you, 155 00:16:51,180 --> 00:16:57,980 we say you have some unit of nonce value within our system of stuff. And so that means two things. 156 00:16:57,980 --> 00:17:03,580 One, you can generate nonces based on your big old clusters of stuff. And then when you sign it 157 00:17:03,580 --> 00:17:10,860 and whatever other nonsense of hashing, that means you've basically created money. And now, uh, you 158 00:17:10,860 --> 00:17:16,380 have a big, a piece of Bitcoin or whatever. And second, it means that like, as we introduce more 159 00:17:16,380 --> 00:17:22,860 of these nonces, uh, you can do another verification of your, uh, your turtles all the way down hashing 160 00:17:22,860 --> 00:17:27,980 of you generated this nonce and then you gave it to this other person. And then we did a, we did a 161 00:17:27,980 --> 00:17:33,820 hashing package. And now we know that this other person has that nonce. And then we all have like, 162 00:17:33,820 --> 00:17:39,740 we basically got this distributed ledger that's scurrying around. And, uh, whenever, whenever we want to 163 00:17:39,740 --> 00:17:44,540 verify that someone actually owns a nonce, we can just sort of like play around with that and do all 164 00:17:44,540 --> 00:17:49,580 sorts of stuff. And we can verify that, uh, that this person actually has this, this money, if you 165 00:17:49,580 --> 00:17:54,620 will. And then at some point you all, but then you also have to like set the exchange rate or a value 166 00:17:54,620 --> 00:18:01,580 of, I guess you can, you can do the old, uh, I will accept five of your nonces for making a logo for you, 167 00:18:01,580 --> 00:18:06,460 or I'll accept whatever the exchange rate is, 10 of them to equal a dollar. And then you can cash 168 00:18:06,460 --> 00:18:11,980 out at that point. Uh, well cash out into the, the old school world. Sure. All right. Now I know 169 00:18:11,980 --> 00:18:16,140 it's figured out and there's some magic math in there with hats, hashes. Yeah. And if you just 170 00:18:16,140 --> 00:18:22,060 replace, uh, in the mental model nonces with Bitcoin, because the value is finding the nonce, 171 00:18:22,060 --> 00:18:27,100 but you are rewarded with Bitcoin after you find one, then that's, that's exactly accurate what you 172 00:18:27,100 --> 00:18:32,460 said. So, so easing in, I will, instead of me leading it. So tell me how, so given that example 173 00:18:32,460 --> 00:18:37,020 of like, you got all these Bitcoin currency markets. So what are, what are other applications of, 174 00:18:37,020 --> 00:18:40,780 of, of a blockchain chain technology? I mean, just, just kind of list off some of the other 175 00:18:40,780 --> 00:18:46,140 ways that, that you would use this. And then we can kind of, uh, go into, uh, some of your favorites 176 00:18:46,140 --> 00:18:50,460 and then more importantly, how you would, uh, you would integrate it into a cloud foundry environment. 177 00:18:50,460 --> 00:18:56,380 Sure. So, uh, that is just one example where Bitcoin is very limited in their thought process 178 00:18:56,380 --> 00:19:01,340 of, um, you can only exchange Bitcoin. You can't exchange anything else. There's no way to encrypt 179 00:19:01,340 --> 00:19:05,500 other information because remember that we're saying that the 30 byte string is all that you get. 180 00:19:06,060 --> 00:19:14,140 And, um, you know, but if you expand that idea, um, and you are able to transfer data back and forth, 181 00:19:14,140 --> 00:19:18,780 that can be of whatever size you want. And you only have to verify that it satisfies some 182 00:19:18,780 --> 00:19:26,380 transaction hash, then you can, um, replace the base level with whatever data structures you might want. 183 00:19:27,180 --> 00:19:33,260 And that's very valuable because replacing data structures under that whole verification process 184 00:19:33,260 --> 00:19:40,380 and that consensus algorithm that is, that is, um, widely under review as much more reliable than say, 185 00:19:40,380 --> 00:19:46,060 just trusting some CA or trusting that all of the nodes won't be compromised at some point. Um, 186 00:19:46,060 --> 00:19:53,740 you are solving a problem that's allowing you to send data back and forth reliably of any sort. 187 00:19:53,740 --> 00:20:01,580 So if I wanted to, for example, send some other part of my application, uh, some application state, 188 00:20:01,580 --> 00:20:07,580 like, Hey, this person just made a purchase and I need you to send that purchase to the factory 189 00:20:07,580 --> 00:20:12,460 so that the factory knows they need to make some shoes for this person who just bought. 190 00:20:12,460 --> 00:20:19,980 All right. No, that's good. Or to add another layer to that, um, uh, we, we, to be funny about it, 191 00:20:19,980 --> 00:20:26,940 us here at downtown central headquarters, uh, we, we're authorizing you to manufacture 5,000 pairs 192 00:20:26,940 --> 00:20:31,420 of shoes. And at the factory, you would like to know, like that was actually them telling me to 193 00:20:31,420 --> 00:20:34,860 generate the shoes so that two weeks from now, I don't call them up and they're like, what do you 194 00:20:34,860 --> 00:20:41,580 mean manufacture 5,000 shoes? But you can verify that, uh, that a faceless command, so to speak, 195 00:20:41,580 --> 00:20:43,180 actually came from the right source. 196 00:20:44,140 --> 00:20:50,780 Exactly. And that's very valuable, right? Because we don't have to then have this crazy system of 197 00:20:50,780 --> 00:20:54,780 making sure that everything's signed and everybody's like talking to each other and, 198 00:20:54,780 --> 00:20:59,740 you know, because we don't like to talk to each other, but we can just, as, as, uh, as, 199 00:20:59,740 --> 00:21:05,180 as our, our friend Bezos says, communication is failure. So it's, it's, uh, it's, it's good not 200 00:21:05,180 --> 00:21:10,860 to have to talk with each other. Yeah. Cause if we can automate the process and make it just 201 00:21:10,860 --> 00:21:20,620 simpler for people to do their job, then it's a much simpler, uh, model. But, um, when you make 202 00:21:20,620 --> 00:21:28,300 these data transactions, then, um, blockchain providers started thinking of, hmm, I don't 203 00:21:28,300 --> 00:21:34,540 really have to, uh, well, there's two approaches really. So there's the open source approach of we 204 00:21:34,540 --> 00:21:39,660 should allow anybody to write whatever they want onto a blockchain and use application development 205 00:21:39,660 --> 00:21:44,700 practices to distinguish what they want to put in. And that would be something like Ethereum, 206 00:21:44,700 --> 00:21:50,460 which I'll come back to later because it's my favorite. But then if we talk about something 207 00:21:50,460 --> 00:21:57,020 like Ripple, which is a financial institution, transactional service that uses blockchain, 208 00:21:57,020 --> 00:22:05,820 or we talk about something like, um, R3's Corda, then we're talking about something that uses, um, 209 00:22:05,820 --> 00:22:11,820 this idea of, I should be able to put whatever data I want and have behavior that exists, um, 210 00:22:11,820 --> 00:22:17,340 on the blockchain, but you're not opening it up to developers and you're not opening it up to a 211 00:22:17,340 --> 00:22:24,620 wider community. So, um, Ripple based on the fact that they're keeping things confined, uh, 212 00:22:24,620 --> 00:22:32,060 not only allows them to refine their product more comprehensively on top of a blockchain, 213 00:22:32,060 --> 00:22:39,260 but it also allows them to change out their blockchain implementation. So, um, their blockchain 214 00:22:39,260 --> 00:22:45,580 implementation doesn't use that GPU farming that we talked about where it's, you have to find a nonce 215 00:22:45,580 --> 00:22:52,940 value. That is just something that you would never know. Uh, they use proof of reputation where the 216 00:22:52,940 --> 00:22:58,060 more that a node has contributed and the more transactions that the node has signed that have 217 00:22:58,060 --> 00:23:06,940 been committed onto the ledger as valid, um, the more reputable they'll be. So if some new node shows up, 218 00:23:06,940 --> 00:23:12,140 anybody can join the network, but if some new node shows up and starts signing transactions left and 219 00:23:12,140 --> 00:23:17,260 right that conflict with one another, and they don't make sense, then people will eventually start 220 00:23:17,260 --> 00:23:23,580 ignoring that node. And it won't matter what they say just as a part of their reputation. They'll 221 00:23:23,580 --> 00:23:28,780 identify that. Oh yeah. Node number five over there. He's been yelling about some kind of nonsense for 222 00:23:28,780 --> 00:23:35,820 too long. So we ignored him. And that allows them to not have that latency of you need to find a nonce 223 00:23:35,820 --> 00:23:42,700 value. You can immediately, um, use your reputation to verify that the transaction that you're pushing 224 00:23:42,700 --> 00:23:47,580 is valuable. But remember that that's exactly what we wanted to get away from in our blockchain 225 00:23:47,580 --> 00:23:53,340 implementation. Because, um, you could theoretically just sign a whole bunch of transactions and then 226 00:23:53,900 --> 00:23:58,700 at the end of the day say, haha, I'm just kidding. I wanted to do this evil thing all along and sign 227 00:23:58,700 --> 00:24:05,180 something that's bad. Right. Right. So it's good for a private model. I think that Ripple has a very 228 00:24:05,180 --> 00:24:12,220 good blockchain idea for their model because they can ensure some sort of data security and integrity 229 00:24:12,220 --> 00:24:18,940 behind the scenes. Um, Corda operates mostly the same way, except they've started to move a little bit 230 00:24:18,940 --> 00:24:27,740 more towards application development where you are allowed to use their, uh, special execution environment 231 00:24:28,540 --> 00:24:35,260 to run an application that does verification of whatever, uh, data it is that's being written onto 232 00:24:35,260 --> 00:24:41,500 the blockchain. So for example, they, they focus more on financial institutions. So they might have, 233 00:24:41,500 --> 00:24:50,540 say bank A and bank B bank A has some API that they can call from that execution environment that Corda 234 00:24:50,540 --> 00:24:58,220 is providing that will say, yep, that transaction looks good. I say that it's fine. And then they also 235 00:24:58,940 --> 00:25:06,940 have, um, another side of it that will ask bank B if the same transaction is something that should go 236 00:25:06,940 --> 00:25:14,780 through bank B might say, no, that doesn't look good. And so the whole transaction cancels. But if bank B says, 237 00:25:14,780 --> 00:25:22,220 no, that looks good. Then you've allowed both banks to provide their own value in their verification 238 00:25:22,220 --> 00:25:30,220 process. So that's getting a little bit closer to what we think of, um, as how you would use a distributed 239 00:25:30,220 --> 00:25:34,060 system in a replicable environment to process data, right? 240 00:25:34,060 --> 00:25:38,220 Yeah. It's a whole like, uh, uh, I don't know, sort of, uh, what do they call it? 241 00:25:38,220 --> 00:25:43,260 Like election sort of stuff when it comes to distributed data verification of having multiple 242 00:25:43,260 --> 00:25:48,380 nodes sort of weigh in if this thing is true or not. And then, and then obviously as maybe you're 243 00:25:48,380 --> 00:25:53,500 going to get into, there's all sorts of heuristics of how, if, if you trust that, uh, a yes or no vote from, 244 00:25:53,500 --> 00:26:01,580 from something. Sure. So I can, I can actually, um, I'll, I'll move back a second and talk about the 245 00:26:01,580 --> 00:26:07,660 lower level problem that both blockchains and distributed systems in general try to solve. 246 00:26:07,660 --> 00:26:14,380 And the problem is called the business team generals problem. I'm from, I'm pretty sure I just, uh, 247 00:26:14,380 --> 00:26:22,700 mispronounced that, but it's okay. So you're supposed to imagine three generals that are all 248 00:26:22,700 --> 00:26:31,020 encircling a command post that they intend to either attack or retreat from as they're encircling this 249 00:26:31,020 --> 00:26:38,780 command post. Uh, how do you verify whether or not they will attack or retreat? And we can talk, 250 00:26:38,780 --> 00:26:44,300 um, for another, if you wanted to, we could talk for another three hours about how, um, 251 00:26:44,300 --> 00:26:50,540 I can always assume retreat until I hear otherwise, or I can always assume attack until I hear otherwise, 252 00:26:50,540 --> 00:26:56,940 or, um, I send somebody over, but they get killed. So I have to send three people over because it's 253 00:26:56,940 --> 00:27:02,860 much less likely that with that redundancy, everybody would be killed or intercepted on their way to 254 00:27:02,860 --> 00:27:10,380 general that I want to tell my information to. And so we get into this issue, um, where if we work out 255 00:27:10,380 --> 00:27:18,060 all of the problems, we basically need two thirds of the generals to be in agreement for you not to, 256 00:27:18,060 --> 00:27:25,500 um, fail against this attack. Because if two thirds of the generals agree, it's in the third general's 257 00:27:25,500 --> 00:27:32,620 best interest to, um, not lie and to play by the rules, just by how the, um, how the system would 258 00:27:32,620 --> 00:27:38,220 work. Where if the third general retreated and the other two attacked, they would obviously know that 259 00:27:38,220 --> 00:27:46,460 he was ignoring them. Right. Or if the opposite was exactly true, then they'd be like, uh, that's not 260 00:27:46,460 --> 00:27:53,020 good. Like you probably shouldn't have done that. Um, so we can run into this problem in a real scenario 261 00:27:53,020 --> 00:28:02,300 where, uh, if you imagine a, uh, I had this example up here with, um, NASA actually had this issue with 262 00:28:02,300 --> 00:28:11,580 a flight control system, um, that would fail given a certain small set of conditions that was considered 263 00:28:11,580 --> 00:28:19,900 out of specification. And because they never, um, designed a system against that potential failure, 264 00:28:20,540 --> 00:28:26,780 then the whole system would crash as soon as one thing got out of agreement. So it was as small as, 265 00:28:27,660 --> 00:28:35,500 um, an accelerometer could be potentially like halfway off what it should be. And everybody would 266 00:28:35,500 --> 00:28:41,420 like completely lose their mind in the system and everything would shut down. Right. Because they 267 00:28:41,420 --> 00:28:47,740 didn't design with the thought process in mind that hardware might fail. And so we also should be 268 00:28:47,740 --> 00:28:53,500 planning for that kind of low level, um, nodes can be compromised and nodes can fail. 269 00:28:54,220 --> 00:28:58,620 And moving up from that is where we got to blockchain and where we got to these implementations. 270 00:28:59,660 --> 00:29:08,940 So returning to our example in blockchain, uh, the ripple is assuming that everybody's going to be 271 00:29:08,940 --> 00:29:15,980 reputable or that you can use the weight heuristics. Corda is going to assume that the external APIs are 272 00:29:15,980 --> 00:29:23,100 always going to be available and that the external APIs will always be reputable, which is, 273 00:29:24,060 --> 00:29:28,380 you know, you can talk about how reasonable that is based on what the implementations are. 274 00:29:28,940 --> 00:29:37,500 But my personal favorite is, um, both hyper ledger, uh, from IBM and Ethereum from the Ethereum foundation 275 00:29:38,380 --> 00:29:45,660 are moving more towards this idea of, uh, we should provide a platform for people to write 276 00:29:45,660 --> 00:29:51,260 their own rules on what should go into the blockchain and how you can access that data. 277 00:29:51,260 --> 00:29:51,740 Hmm. 278 00:29:51,740 --> 00:30:00,140 So now you can have this idea of these smart applications that are, um, always running in 279 00:30:00,140 --> 00:30:04,300 the same environment, no matter what node you're pinging throughout the entire network. 280 00:30:04,860 --> 00:30:12,860 So I can write one thing. So I say that I'm just going to publish my application onto the blockchain, 281 00:30:12,860 --> 00:30:18,700 and that's called a smart contract because it's basically, um, a contract that you're signing 282 00:30:18,700 --> 00:30:22,300 when you, uh, hit the blockchain and say, yep, I'd like to be a part of that. 283 00:30:23,180 --> 00:30:29,580 So the smart contract is like a big application that can be reproduced on any of the nodes throughout 284 00:30:29,580 --> 00:30:36,780 the blockchain. And I'm going to publish mine. And I'm going to say, if any shoe manufacturers 285 00:30:37,340 --> 00:30:42,540 would like to take these orders, this is what you need to do. And here's an endpoint that you need 286 00:30:42,540 --> 00:30:49,180 to hit to say, you want to claim the order. Um, so then shoe manufacturers might check in and they'd 287 00:30:49,180 --> 00:30:57,340 say, okay, it seems like Gary has 5,000 shoes that he needs to be made. And I can continue to update that 288 00:30:57,340 --> 00:31:06,380 as I get more orders for shoes. They can then update in a reputable way using the blockchain technology 289 00:31:06,380 --> 00:31:10,940 and say, I'd like to take that order for 500 shoes. And then another person comes in and they say, 290 00:31:10,940 --> 00:31:17,340 I'd like to take that order for 1000 shoes. And we don't have this problem of double spending where 291 00:31:17,340 --> 00:31:22,220 too many shoes would get made because the verification process for blockchain is extensive 292 00:31:22,220 --> 00:31:28,300 and you would never have that issue using some kind of proof of work or proof of authenticity, 293 00:31:28,860 --> 00:31:37,020 claim. And then, um, you would have a record of everything that was said. So if the shoe manufacturer 294 00:31:37,020 --> 00:31:43,900 shipped me 50,000 shoes, when I only asked for 500, I'd be able to go back and verify that they said they 295 00:31:43,900 --> 00:31:49,660 would only make 5,000 and they would only charge me for 5,000. Right. Right. So, so like, like, like in 296 00:31:49,660 --> 00:31:57,900 this example, how, like, what are the usual ways that like all the, all the data in, in the ledger, 297 00:31:57,900 --> 00:32:03,580 so to speak is like distributed, right? So you just named three entities there, right? Who, who in theory 298 00:32:03,580 --> 00:32:08,460 have their own corporate networks and servers and all that stuff and stuff that runs their APIs. Like, 299 00:32:08,460 --> 00:32:15,020 like, are there just like hourly batch jobs that run that like, I'm sure they don't FTP, 300 00:32:15,020 --> 00:32:20,380 but that transfer like this data around and then you update your, uh, your own block, your, your sort 301 00:32:20,380 --> 00:32:25,740 of like local copy, so to speak of the blockchain, or like, is it always centralized somewhere or like, 302 00:32:25,740 --> 00:32:33,020 where's the distributed nature come in to, to that? So that's where, um, each of those big batches of 303 00:32:33,020 --> 00:32:39,980 transactions and nonce values and signed keys that give you that value. If we run back to Bitcoin, 304 00:32:40,780 --> 00:32:46,220 that whole data structure is called one block. So you would say all of those transactions exist in 305 00:32:46,220 --> 00:32:53,820 that one block. And now that block is history. I can assume that all of those transactions have happened. 306 00:32:54,460 --> 00:33:02,540 And when you start your blockchain node and you use a blockchain client, then you are always operating 307 00:33:02,540 --> 00:33:09,980 off of the assumptions that that block has already happened. So based on the nature of the blockchain, 308 00:33:11,500 --> 00:33:18,140 you would always have the point where transactions would either be verified or ignored based on the 309 00:33:18,140 --> 00:33:25,500 previous state of the ledger. So if you see a new block that's higher number than the block that you're 310 00:33:25,500 --> 00:33:32,860 on, you have two choices. I'm either going to ignore this block and try to make my own version of the 311 00:33:32,860 --> 00:33:38,300 blockchain, which people will inevitably ignore because they see higher block numbers than the ones that 312 00:33:38,300 --> 00:33:44,860 you're producing by yourself. Or you can accept the new reality and build your transactions based on this 313 00:33:44,860 --> 00:33:51,020 new set of history. It becomes a problem of if you want to contribute, then you either have to have 314 00:33:51,020 --> 00:33:58,060 more power than everybody else to make your own set of block, or you can use the blocks that exist and 315 00:33:58,060 --> 00:34:03,580 that everybody's contributing to. And you can build on that version of history to make your application 316 00:34:03,580 --> 00:34:07,580 reputable. All right, I think that makes sense. That's the file system that you're talking about. 317 00:34:07,580 --> 00:34:12,300 That's that whole ledger is that those blocks, once they happen, you can't change them. 318 00:34:12,300 --> 00:34:17,900 Right. And, and, and so, so kind of, well, depending on the accuracy and ease of what you want to 319 00:34:18,620 --> 00:34:23,980 verify past events with your own, uh, with your own copy of the blockchain thingy, 320 00:34:24,540 --> 00:34:29,820 uh, you basically always have to be accepting the new, the new nonsense that are in the system and 321 00:34:29,820 --> 00:34:35,020 figuring out if it makes sense to add them to your own. And then, and then you, and so you could, 322 00:34:35,020 --> 00:34:40,220 if you were the manufacturer and, and you're, uh, you've got the two manufacturing companies, 323 00:34:40,220 --> 00:34:45,260 one wants to make 5,000, the other wants to make a thousand. And if your network goes down for a day, 324 00:34:45,260 --> 00:34:49,980 you'll have to spend some time going to those two, those two, uh, other manufacturers and getting 325 00:34:49,980 --> 00:34:54,220 all the nonsense they've created and deciding whether or not you add it to your blockchain. 326 00:34:54,700 --> 00:34:59,340 But then once you do that, you can go verify, you can go see these orders have come in and verify 327 00:34:59,340 --> 00:35:02,620 that they were actually orders from, uh, from those two manufacturers. 328 00:35:02,620 --> 00:35:08,220 Right. So you would assume that all of the blocks participating in a certain chain 329 00:35:08,220 --> 00:35:13,260 would be sharing the same ledger. So both of the companies, both of the manufacturers would be 330 00:35:13,260 --> 00:35:19,580 using, um, essentially your chain and they could communicate between themselves as well that, 331 00:35:19,580 --> 00:35:24,860 you know, no, I got that order first. I got that order first. There's no argument. It's just whoever 332 00:35:24,860 --> 00:35:31,660 got into the chain first and who got the transaction in first. And you can do like timestamps inside of 333 00:35:31,660 --> 00:35:35,820 the transactions to make sure that whoever did what first actually did do it first. 334 00:35:35,820 --> 00:35:43,740 Yeah. Well, all right. No, I, I think that makes enough sense, but, and so, and so before we run 335 00:35:43,740 --> 00:35:49,180 out of time, so how does all this fit into, uh, into, you know, uh, things you've been doing in 336 00:35:49,180 --> 00:35:53,100 Cloud Foundry? Like what do you use it for in, uh, in a cloud platform like that? 337 00:35:53,100 --> 00:35:58,380 So we can, um, one of the things that we wanted to do was that apparently customers are having a 338 00:35:58,380 --> 00:36:04,140 problem being able to verify their operational state or the operational state of certain applications. 339 00:36:04,860 --> 00:36:11,100 And we built, um, just as an example for a POC, we built a distributed ledger system that's, um, 340 00:36:11,820 --> 00:36:18,380 running inside of a cloud so that we can, um, run that as much as we want and we can hook it up to 341 00:36:18,380 --> 00:36:24,220 something that's sitting in the backend to verify that, um, the IAS and that Bosch and that the cloud 342 00:36:24,220 --> 00:36:25,980 are all seeing the same thing at the same time. 343 00:36:25,980 --> 00:36:30,380 Oh, that's interesting. Right. And then that gets to the point that like in a, a fast, 344 00:36:30,380 --> 00:36:34,780 a really fast moving, highly distributed system with like multiple nodes doing things, 345 00:36:34,780 --> 00:36:39,980 you essentially want some way of saying like, well, most, all of these nodes think they're doing 346 00:36:39,980 --> 00:36:44,300 all right. And then therefore we can kind of conclude that everything is running at the, the, 347 00:36:44,300 --> 00:36:48,300 whether you want to call it service level objectives or SLAs or whatever, like they're 348 00:36:48,300 --> 00:36:53,740 all operating at a level that we find, uh, acceptable. So we don't need to try to fix the 349 00:36:53,740 --> 00:36:59,580 problem that's going on. And then more importantly, um, we, we have, and it could be timestamped as well, 350 00:36:59,580 --> 00:37:04,780 but we have a verification that this is actually the, the state in, in the time that we want of 351 00:37:04,780 --> 00:37:09,740 all of this stuff. We can trust all of the, uh, the, the metrics that we've gathered about health. 352 00:37:09,740 --> 00:37:13,980 Absolutely. And the other side of it is, um, we're trying to deliver the value because everything that 353 00:37:13,980 --> 00:37:18,940 we just talked about, I mean, we've been sitting here for 45 minutes and, um, I'm pretty sure that 354 00:37:18,940 --> 00:37:23,900 it would still be difficult to get started on an actual like implementation. If you had an amazing 355 00:37:23,900 --> 00:37:32,220 idea just city of blockchain. So we're trying to give Ethereum, um, is our blockchain of choice at the 356 00:37:32,220 --> 00:37:39,260 moment. And they, um, we're trying to provide that as a service. We're trying to say that you can just 357 00:37:39,260 --> 00:37:44,780 use Ethereum and we will provide all of the backend awfulness that you don't want to deal with. And 358 00:37:44,780 --> 00:37:50,300 all you have to worry about is writing your application and making it work with a Ethereum 359 00:37:50,300 --> 00:37:56,060 node that could exist anywhere. So that's, that's the value that we're trying to deliver in, um, in our 360 00:37:56,060 --> 00:38:01,180 space so that we can kind of say, you know, go out and play with it, do something that you think is 361 00:38:01,180 --> 00:38:04,780 valuable with the application development that you're working on. 362 00:38:04,780 --> 00:38:09,580 And then this would, this would essentially be like a, a fully integrated, ready to use just 363 00:38:09,580 --> 00:38:14,220 service in a cloud foundry instance, right? So you wouldn't have to, uh, figure out how to package 364 00:38:14,220 --> 00:38:18,540 it all together and all that. You could just do the usual, like, you know, adding a tile or however 365 00:38:18,540 --> 00:38:23,340 people want to call it in their, their distro, but just on the command line, a product, an application 366 00:38:23,340 --> 00:38:26,140 team could just add it in and start using that service. 367 00:38:26,140 --> 00:38:30,140 Exactly. And we're still, you know, it's still, um, blockchain is changing all the time. 368 00:38:30,140 --> 00:38:36,620 So we're still at the development phase of, um, we should be using it to investigate potential 369 00:38:36,620 --> 00:38:41,980 sources of value and building on what we can. And it's very difficult to do that if you can't 370 00:38:41,980 --> 00:38:47,180 actually use the blockchain because it's too awful to set up. So if we had a Bosch release that would 371 00:38:47,180 --> 00:38:53,420 give you a blockchain that you could just use and you could scale using Bosch or with cloud foundry, 372 00:38:53,420 --> 00:38:57,660 then that would provide value, right? Because then you have all of the greatness of cloud foundry and 373 00:38:57,660 --> 00:39:03,740 Bosch and replication and distributing across environments and different networks and availability 374 00:39:03,740 --> 00:39:04,860 zones and all of that. 375 00:39:04,860 --> 00:39:10,060 So, so then, then I guess to, to in, in my way, grossly generalize it, right? So you add in, uh, 376 00:39:10,060 --> 00:39:13,340 well, what, what, what do you, what do you guys, what do you call this? What's the name of this, 377 00:39:13,340 --> 00:39:15,100 this thing, this project or whatever? 378 00:39:15,100 --> 00:39:17,020 Uh, we're just calling it Ethereum as a service. 379 00:39:17,020 --> 00:39:19,020 There you go. So blockchain as a service. 380 00:39:19,020 --> 00:39:24,380 So if, if you have, if you have Ethereum in, uh, in your cloud foundry setup, the, 381 00:39:25,100 --> 00:39:31,180 the simplest thing, the simplest way of putting what it provides is a, uh, to use the word again, 382 00:39:31,180 --> 00:39:37,900 or let's say a verifiable log of things that have happened. Now, what those things are is like the 383 00:39:37,900 --> 00:39:42,940 next step. So you can always verify to say, I guess you can't verify that what was claimed happened, 384 00:39:42,940 --> 00:39:49,660 happened, so to speak, but you can verify that something, something, uh, something said that 385 00:39:49,660 --> 00:39:54,860 something happened, right? Uh, so, so a node on its own might've evaluated itself and said like, 386 00:39:54,860 --> 00:39:59,260 I'm healthy or something like that. So, so then what that means is you at least have two different 387 00:39:59,260 --> 00:40:03,740 things on the, uh, let's call it business capability front. However, you might want to use 388 00:40:03,740 --> 00:40:08,700 that. And we went over a few examples with our manufacturing thing, or just like a pure currency, 389 00:40:08,700 --> 00:40:14,460 or I guess bank ledgers would be another example, or, um, also the way that insurance companies keep 390 00:40:14,460 --> 00:40:20,140 their books or, or whatever. Uh, you could provide just as a capability for your application. 391 00:40:20,140 --> 00:40:25,020 We now have a verifiable ledger that we can use. However, you can think of business-wise. 392 00:40:25,020 --> 00:40:28,220 So that would be something you could do with it. And then the second thing that we alluded to a 393 00:40:28,220 --> 00:40:33,740 little bit is more of more or less like you could be providing a service that other people use to 394 00:40:33,740 --> 00:40:38,300 build applications, which is a whole other thing, but let's set that aside. But internally, 395 00:40:38,300 --> 00:40:43,180 you could use it as a way to verify things that are happening in your own cloud foundry instance. 396 00:40:43,180 --> 00:40:48,300 So we went over a, um, like a health check, right? Like at any given point, you know, 397 00:40:48,300 --> 00:40:53,660 we can verify that, uh, these nodes at some point thought they were healthy. And so that gives us a 398 00:40:53,660 --> 00:40:58,060 sense of what's going on, but you could, I, I imagine you could also do other things that like, 399 00:40:58,060 --> 00:41:05,180 if you wanted to automate, uh, like deployments and you wanted to automate doing some canary deployments, 400 00:41:05,180 --> 00:41:09,100 you could essentially, the way that you would track. So a canary deployment being like, 401 00:41:09,100 --> 00:41:13,260 I always say the word node. I don't know what the kids say nowadays, but let's say you've, 402 00:41:13,260 --> 00:41:19,980 you've got 500 nodes and you want to, you want to roll out changes to just five of them and see if it 403 00:41:19,980 --> 00:41:24,220 worked. And then if it works, you're going to roll out changes to 20 more of them and then 50, 404 00:41:24,220 --> 00:41:28,940 and then finally to 500. And you do this incrementally so that you don't break, uh, 405 00:41:28,940 --> 00:41:35,020 too much of production. So you need some way of the more automated you want to do of tracking if 406 00:41:35,020 --> 00:41:40,140 anything was broken or not. And you could use the centralized ethereum, whatever ledger of 407 00:41:40,140 --> 00:41:45,660 verifiability to go in and check, like, were those first five nodes good? And can I trust that they're 408 00:41:45,660 --> 00:41:49,260 the ones who said they were good and the next 10 nodes and so on. And so you could have a central 409 00:41:49,260 --> 00:41:54,140 ledger of everything was hunky dory. And now we can, uh, we can roll out the change. And then I guess 410 00:41:54,140 --> 00:41:57,980 that has, that has another exciting side effect. If you're worried about like, you know, three ring 411 00:41:57,980 --> 00:42:04,700 binder ninjas of audit and compliance, you've got like a log of, of, of a, not only a log of events 412 00:42:04,700 --> 00:42:09,980 happening, but a log of a disciplined approach to something happening. Cause you know, compliance 413 00:42:09,980 --> 00:42:15,740 people in, in, in an overly nuanced kind of way, they're usually interested that you had a process 414 00:42:15,740 --> 00:42:20,780 and you followed the process and it's not really their job to worry about if things were successful 415 00:42:20,780 --> 00:42:27,020 or not. Exactly. And if you write it into a blockchain contract, exactly what you said with 416 00:42:27,020 --> 00:42:33,580 compliance. If I'm writing something literally called a smart contract, I can write a contract 417 00:42:33,580 --> 00:42:39,660 that runs code. And when that code is run, it is verifiable that it happened based on everything 418 00:42:39,660 --> 00:42:44,460 that we've covered. And then you can say, yep, I did exactly what I needed to do. And the rest of it 419 00:42:44,460 --> 00:42:49,660 is you can do whatever you need with the rest of the data. Right. And, and, and then on the extreme 420 00:42:49,660 --> 00:42:56,620 end, in contrast, I mean, as, uh, there's a great, uh, a great talk from, uh, uh, this guy, I think it 421 00:42:56,620 --> 00:43:01,900 was, no, it was HCSC, this guy, Mark at a big health insurance company. And his point was, I mean, 422 00:43:01,900 --> 00:43:06,620 it's, it's sort of difficult, but like, you know, you can just write whatever you want in a log file 423 00:43:06,620 --> 00:43:12,380 and zip it up and send it to a compliance person. But one, it's very difficult to take all of your, 424 00:43:12,380 --> 00:43:17,260 you know, sort of, let's say your get, your get logs and your Jenkins logs and your PCF logs, 425 00:43:17,260 --> 00:43:21,740 like theoretically, uh, in the same way that theoretically with some paper, you could come up 426 00:43:21,740 --> 00:43:26,220 with nonsense if you lived long enough, but theoretically you could falsify all those logs, 427 00:43:26,220 --> 00:43:31,180 but it's very hard to falsify them. And then another layer would be that the only way that 428 00:43:31,180 --> 00:43:35,180 we're going to trust all this package of these logs that you're giving is if it's been, you know, 429 00:43:35,180 --> 00:43:40,060 it's participating in our blockchain essentially, and we verify it through there. So you have, 430 00:43:40,060 --> 00:43:44,860 you have as rock solid as we can hope for. I mean, there could always be some extraterrestrial 431 00:43:44,860 --> 00:43:49,500 entities that like operate under different ways that we don't, and we don't know about who are 432 00:43:49,500 --> 00:43:54,780 falsifying, uh, you know, the fact that, you know, George put this hat on a cat and then just the whole 433 00:43:54,780 --> 00:44:01,020 system would be flawed, but whatever. But as best as we can hope for with our current understanding 434 00:44:01,020 --> 00:44:06,860 of reality, we can verify that this thing, this thing, that this, that a system said this thing 435 00:44:06,860 --> 00:44:11,740 happened, uh, basically. Absolutely. And that system is distributed. It's not one computer. 436 00:44:12,300 --> 00:44:16,380 Right. Right. Exactly. Yeah. Well, that sounds good. Was there anything else you want to preview 437 00:44:16,380 --> 00:44:21,180 from your talk before we wrap up? Uh, no, I think, um, I think we hit all the major points and you're 438 00:44:21,180 --> 00:44:26,060 just going to have to be at CF summit if you want to hear the rest of it. Exactly. Well, before I wrap 439 00:44:26,060 --> 00:44:30,380 up, so if people want to, uh, catch up with you or like, just see what you're doing, like what, uh, 440 00:44:30,380 --> 00:44:35,500 what would you point them at over there on the internet? Uh, yeah, so I can give my GitHub. Um, 441 00:44:35,500 --> 00:44:41,740 I'm usually committing to a few rebotes in the EMC dojo, uh, repository there. So it's, um, 442 00:44:41,740 --> 00:44:46,380 just Gary P white. I am not creative at all. I didn't come up with something clever. It's just 443 00:44:46,940 --> 00:44:51,980 my name with the P in the middle. Well, it put, it puts you in the exclusive club of people who 444 00:44:51,980 --> 00:44:57,340 like to have their middle initial. It's very, very noble. Yeah. Well, it came out when I put 445 00:44:57,340 --> 00:45:01,420 it on Facebook because there's way too many Gary whites. If you look on Facebook, there's like, 446 00:45:01,420 --> 00:45:05,340 Oh my God, too many. I bet. And you have a Twitter account or anything like that? No, 447 00:45:05,340 --> 00:45:11,180 I do not. Oh, very nice. Another exclusive club. I know. Don't bother me. 448 00:45:11,180 --> 00:45:17,020 And then, um, I can do, uh, I can do emails. I will, I am always checking my email at least 449 00:45:17,020 --> 00:45:21,420 once a day as a developer. I have the luxury of not having it open all the time, but it's just, 450 00:45:21,420 --> 00:45:27,260 um, it's all Gary P white at live.com. So it's the same as the GitHub handle, but it's just 451 00:45:27,260 --> 00:45:32,300 at live.com. That's right. So if, if, if, uh, you know, at Twitter, don't go knocking on your 452 00:45:32,300 --> 00:45:36,300 door cause you're not home essentially. Well, well, thanks for being on that. That was good. I feel, 453 00:45:36,300 --> 00:45:41,980 I feel like I know, uh, you know, maybe 10 to 20% more about blockchain, which, which is, 454 00:45:41,980 --> 00:45:46,060 which is not your fault of explanation. It's just that it's, it's a, uh, it's a complicated subject, 455 00:45:46,060 --> 00:45:51,420 but it's very, but that that's, that's infinite growth from what I knew earlier. So that's fantastic. 456 00:45:51,420 --> 00:45:59,580 10 to 20%, you know, it's still zero. So perhaps so, but no, no, more seriously, that's, that's, uh, 457 00:45:59,580 --> 00:46:04,060 that's, that's good stuff. And so as always, thanks for listening. This has been Pivotal Conversations. 458 00:46:04,060 --> 00:46:09,260 If you want to get the most recent episodes without having to poke around in your web browser, 459 00:46:09,260 --> 00:46:13,900 whatever you just go, you can look around in your iTunes or your overcast or whatever thing you use, 460 00:46:13,900 --> 00:46:18,060 and just look up Pivotal Conversations and subscribe to the podcast and all the episodes will be 461 00:46:18,060 --> 00:46:23,740 downloaded. Now, if you prefer a slower podcast method, uh, you know, you're cooking your greens and 462 00:46:23,740 --> 00:46:27,420 you're waiting for them to cook and you wanted to live that slow provincial life. You can also go to 463 00:46:27,420 --> 00:46:33,020 soundcloud.com slash Pivotal Conversations, all one word and see all the past episodes and find a link 464 00:46:33,020 --> 00:46:38,140 to the RSS feed and other things like that. Get a sampling of what's going on. And then, uh, we lag in 465 00:46:38,140 --> 00:46:44,300 posting our full, full show notes, but you can see full show notes over at pivotal.io slash podcast. 466 00:46:44,300 --> 00:46:47,820 And then as mentioned earlier, if you're interested in this talk and, and other things in the cloud 467 00:46:47,820 --> 00:46:53,020 foundry and cloud native world. So we've got CF summit coming up. That's a June 13th and 15th 468 00:46:53,020 --> 00:46:58,540 over in, uh, I guess it's the Santa Clara convention center next to that big old Levi's stadium. I've 469 00:46:58,540 --> 00:47:02,300 never verified if you can actually buy blue jeans there or not, that would be fun. Hopefully that's the 470 00:47:02,300 --> 00:47:08,300 case. I think they also do sports there. Uh, but you can go over there, uh, June 13th and 15th. 471 00:47:08,300 --> 00:47:15,260 And if you want to register, you can use the code CFSV17COTE that's C O T E, my name and you get 20% 472 00:47:15,260 --> 00:47:21,180 off. Now that's kind of a mouthful, but it's basically cloud foundry Silicon Valley 17, which 473 00:47:21,180 --> 00:47:24,860 is the year we're currently in last I checked. I might need to go verify that with some nonce or 474 00:47:24,860 --> 00:47:29,020 something. And then you just put my name at the end. And, uh, you can also check out the show notes, 475 00:47:29,020 --> 00:47:34,220 or if, uh, you're lucky enough to have a podcast chapters, if you open it up where I started 476 00:47:34,220 --> 00:47:39,740 yammering about this, you'll see that, uh, that as well. And with that, we'll see everyone next time. Bye-bye.