Blockchain in Cloud Foundry, with Gary P. White (Ep. 62)

Episode 50 · 47:39 · SRT · archive.org · all Tanzu Talk

Well, over the next couple of episodes, we're going to have some, I don't know, to be blunt, some promotional effort to get people interested in the Cloud Foundry Summit. And at the end, I have a little code if you end up wanting to go to get 20% off registration, if you want to go to that. What we're going to have in these episodes is I'm going to talk to some people who are speaking at the Cloud Foundry Summit, just giving a little preview of what they'll be talking about. So why don't you introduce yourself, first guest? I am Gary White. I'm working with the Dell EMC Dojo in Cambridge, Massachusetts. And the talk that I'm going to be giving is building blocks of blockchain, blockchain as a service. And we're going to dive into why you need blockchain, what is blockchain, and what promoted the idea that you're going to need to use it in the future. And then from there, I'll give a demo on something that we've implemented running on Cloud Foundry to give a practical example of how you might use it moving forward. Yeah, well, this would be great, because I don't really know anything about blockchain or anything. Let's start with like, to my ignorance of this, like, what exactly is blockchain? Like, I know the following. There's some sort of cyberpunk named character who's always running around doing it and ledgers. And there's probably some sort of magic, mysterious math that with a lot of curves that I don't understand. So that I'm out. That's all I know. All right. Okay, so we should start. The first thing that you said was that it is a heavy or I think you said it's just a ledger was the leading point. And that's basically the idea is that we have always had this distributed system problem of how do you get everybody to agree on something that needs to happen. So to put it to a bit blockchain example versus a database example, if you can imagine that

there is a MySQL distributed system like Cassandra, where you want to write something into the database. How this would normally work is there would be a pre-elected leader as a node in a Cassandra cluster. So maybe four or five and one of them happens to be the leader. You would ask that leader, hey, I'd like to put this in there. And the leader being the one who's keeping the state of the database would insert it accordingly to when you posted the request. But a problem with that is that if I just continually ask to be the leader, I can become the leader and write whatever I want. And that's kind of where distributed systems start to break down, because it's very difficult to become false tolerance to situations like that. And I can wax and wane about a few more examples that they have in lower level systems like flight control and time synchronization. But blockchain is at its base, a system that is intended to continually provide a verifiable ledger that will make it easier for data to be synchronized across multiple nodes. 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 three main parts. One is it's distributed. And it would be interesting to hear, you know, your explanation of each of these things when it's and by distributed, it means like you don't just have one machine that controls everything. And in theory, you sort of you solve or you address kind of like the the the locking problem, a locking problem being that if you have one piece of data and multiple people want to both read and modify it, you have to have them wait in line to make sure that they get the right data or write, or write the new piece of data correctly without screwing it up. I mean, that's my my fanciful way of defining it. And then

the other thing is, it's basically verifiable. This is the part that I think I think I don't really know how that works. But you can somehow verify that it's accurate, I think, and and then that the the entity or the person who did something is actually the person they claim to be. I don't know. And then, and then and then I guess the third thing is the applications of this mean that there is, there is, I mean, I guess I've never thought of it as 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 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 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 distributed, it's a lot easier for many people to use that data set. And rather than just having one person using it. Absolutely. So in order of those points, I think first one was how do you write where I want to write something, does that mean that I can just immediately call some endpoint and write it? Or do you have a distributed system of everybody reports to some central authority and the central authority would provide the right permissions? So that's, that that's one question where you can either have the central authority at some level or another, that just lets you do what you need to do as long as they say it's cool. But if you can compromise the system that says that it's okay for you to write into the database, then you can write whatever you want. And so that is one of the problems is that you have to make an assumption that the central authority will always either be available because there will never be like a DDoS attack, or that it will always have integrity, right? It hasn't been compromised to

absolutely security terms, right? That makes sense. So that's number one is how do you write? The second one is data integrity, and verification of who and when it was written, where I want to make sure that all of the data that I've written isn't just going to somehow disappear without proper process. And who wrote it and who did what when. So I'm going to try to compress this, so just stop me if I go a little too far. But Bitcoin, for example, does this by using a very clever hashing algorithm that takes an entire transaction as it's written in a certain form. So that transaction might just be a string that says a four character identifier sends to another four character identifier, and then that is followed by an amount. So they know that that's like a 30 byte string or something like that. They would always hash a 30 byte string, and that would produce a transaction hash, so that you would know what the transaction looked like. Because then if somebody hands you a transaction hash that doesn't match the 30 byte string that you provide with it, then you would know that that transaction string was invalid. Does that make sense so far? Yeah, yeah. And that way, that way, I mean, removing for the moment the part of verifying that whoever created that original string that got hashed and inserted into something, let's assume that was all hunky dory, but per your first point. But then that would mean that, like, let's say the two entities are like Twitter handles or something. And it would basically be a way of saying that at one point in time, Person A said that they promised that they would give $5 to Person B. And we can trust that this actually happened because we have it in this record. And so if I want to go,

and if Person B goes and says, I want to convert, like, I want to get that $5 in cash, the ATM system can go look at the magic ledger and kind of like, it can, I guess, recreate that hash and verify that that that actually exists in the ledger of the people. And then therefore, I mean, this gets into the philosophy of money and how it's all actually kind of like, you know, a giant spreadsheet in the sky of funniness. But, uh, but essentially it says this thing happened in the past and therefore you can reliably make decisions like dispensing cash based on it in the present and the future. Yes. And so that, that, that one piece can then also be scaled to make sure that everything in the past is still, um, still has the integrity that you expect. So then you can take all of those hashes that you already have and you can have them hash together and that's called creating a Merkle tree. Um, that's if you want to get really technical. Now that's probably named after the German prime minister, right? Obviously. Most likely. But they, um, when you create a tree, then all of the hashes that created the tree, if you change one of the hashes, then the final hash will change. Right. Right. And that verifies the entire, uh, history of transactions. Absolutely. And then, um, where that like GPU mining comes in, where you think of the warehouses full of, uh, those warring machines that are trying to find some condition. Um, I'm just going to make one up. I'm going to say that, uh, for you to write something onto my blockchain, uh, you have to produce a hash that is starting with zero, zero. And so you can take that whole transaction hash that we just created by hashing a bunch of transactions together and then just continually add things to it. Like you can add one more hash value to try to make it satisfy my

condition. So you have a hash value that's like one, two, three, four, five, and it has to start with two zeros. You would just continually hash it against things that you would just pick out of the ether and it would eventually satisfy the condition. And when you find that one piece, that one hash that you can hash together with all of your transactions, that is called a, um, nonce value. And you would, uh, publish that, uh, signed, uh, signed with your private key along with your transaction ID or your block ID at that point and the list of transactions that you're verifying. And so that's what you would call in, um, Bitcoin's vernacular. You would call that proof of work because you could, um, theoretically guess that nonce value the first time you could be very lucky and satisfy my condition that I've set for the blockchain by taking that transaction hash and then hashing it with the very first thing that you guess. And then it works great. But most of the time it's going to take, um, like they have some mathematical theorem for how long it should take. And based on that theorem, um, they can prove that you didn't just join the network and start writing whatever you wanted. You most likely are participating in the network to get a reward for having done that work. And then, and then my sense is that when you get some nonce you sort of like generated money or something, I don't, and then, but then that gets to my second question is like, so why is that valuable? Like, like, um, I don't know, is there sort of like a scarcity of nonces or something? And those are the things you need to generate in order to represent money. So it's sort of like 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

you're manufacturing the paper that money can be printed on. I don't know, but like, but like, why is it valuable? So valuable to find a nonce that like it, it equals some money sort of thing. So that is such a great question. And I am so happy that you just asked it because if you think of what we talked about with all of those transactions being hashed together, the point of a hashing algorithm is that it's completely random. You have no idea what's going to come out the other side. So when you hash all of those transactions, then you're verifying that all of those transactions are going to be, um, uh, reproducible as the hash that you've provided. So I always know that Gary sent Mike some amount and that's just in a transaction. And then nodes are going to pick these transactions out as they are broadcast throughout the network. And they create this tree until their block is filled with transactions. And they say, Oh, I can't take anymore. So now I'm going to start my nonce procedure. And the nonce is something that you just, there's like, there's no way to know what it is because it's just completely impossible to guess it or to do anything, but guess it because that's how hashing works is you don't know what's going to come out the other side. So when you have this huge transact, this block of transactions, that's verifiable by that one hash, then you can continue hashing against that hash to satisfy some value. So I can hash one, two, three, four and five, six, seven, eight together. And eventually the hash will start with two zeros. And when the hash starts with two zeros, I have proven that these transactions have existed on my, um, system for a long enough time that I was able to find that value that, that nonce value that produces the verification that most

nodes have probably seen this transaction. And so when all of those transactions are verified and I've created the nonce value, I am contributing to the proof that that transaction is valid. And by contributing to the proof that that is valid, I am doing that through the work of finding the nonce value. Does, does that make sense where I think so? Yeah. Yeah. So, so basically the value in like setting up all of these Bitcoin mining things is, uh, you're sort of like contributing to the overall effort of auditing the validity of everything. And then, and so therefore I assume people or people systems that use it sort of like pay you some way, like they, you exchange these nonces that you found in exchange for some form of payment or something, or maybe, maybe the whole system is written that once you contribute a nonce that it automatically like creates value for you or, you know, transfers, I'm putting this in air quotes, transfers money to your account or something like that. Yep. You're exactly right. Because when you transfer that nonce out and you say, hello everybody, I found a block. Then you can sign that block with your private key. So everybody knows it was you and everybody will agree that there is a transaction now that just randomly awards you 25 coins. Okay. Uh, Bitcoin started with 25 and then, um, for reasons of inflation and economics, they, um, they decrease it by half. I think it's every 210,000 coins. Um, they, they reduce the effort, um, or they reduce the value by half. So, so then, so then, so then to try to round out the Bitcoin part, because Bitcoin is, is like, I mean, it's fascinating, but to the point of, of, of your talk, I believe there's all sorts of other things to do with blockchain, but tell me if I've got this right. So in, in the Bitcoin world,

so first of all, there's various types of Bitcoins, right? They got the, the BitBitcoin and the Dogecoin. And, and I think ours, Technica has its own coins. Now those are like separate currencies, right? Or are they, are they related? So you've got these separate currency systems and theoretically there's a set of norms. Whoever participates in these, these, uh, Bitcoin currency markets, they're like, they basically say, if it is verified that you own this nonce, whether you generated it or it's verified that someone gave it to you, we say you have some unit of nonce value within our system of stuff. And so that means two things. One, you can generate nonces based on your big old clusters of stuff. And then when you sign it and whatever other nonsense of hashing, that means you've basically created money. And now, uh, you have a big, a piece of Bitcoin or whatever. And second, it means that like, as we introduce more of these nonces, uh, you can do another verification of your, uh, your turtles all the way down hashing of you generated this nonce and then you gave it to this other person. And then we did a, we did a hashing package. And now we know that this other person has that nonce. And then we all have like, we basically got this distributed ledger that's scurrying around. And, uh, whenever, whenever we want to verify that someone actually owns a nonce, we can just sort of like play around with that and do all sorts of stuff. And we can verify that, uh, that this person actually has this, this money, if you will. And then at some point you all, but then you also have to like set the exchange rate or a value of, I guess you can, you can do the old, uh, I will accept five of your nonces for making a logo for you, or I'll accept whatever the exchange rate is, 10 of them to equal a dollar. And then you can cash out at that point. Uh, well cash out into the, the old school world. Sure. All right. Now I know it's figured out and there's some magic math in there with hats, hashes. Yeah. And if you just replace, uh, in the mental model nonces with Bitcoin, because the value is finding the nonce,

but you are rewarded with Bitcoin after you find one, then that's, that's exactly accurate what you said. So, so easing in, I will, instead of me leading it. So tell me how, so given that example of like, you got all these Bitcoin currency markets. So what are, what are other applications of, of, of a blockchain chain technology? I mean, just, just kind of list off some of the other ways that, that you would use this. And then we can kind of, uh, go into, uh, some of your favorites and then more importantly, how you would, uh, you would integrate it into a cloud foundry environment. Sure. So, uh, that is just one example where Bitcoin is very limited in their thought process of, um, you can only exchange Bitcoin. You can't exchange anything else. There's no way to encrypt other information because remember that we're saying that the 30 byte string is all that you get. And, um, you know, but if you expand that idea, um, and you are able to transfer data back and forth, that can be of whatever size you want. And you only have to verify that it satisfies some transaction hash, then you can, um, replace the base level with whatever data structures you might want. And that's very valuable because replacing data structures under that whole verification process and that consensus algorithm that is, that is, um, widely under review as much more reliable than say, just trusting some CA or trusting that all of the nodes won't be compromised at some point. Um, you are solving a problem that's allowing you to send data back and forth reliably of any sort. So if I wanted to, for example, send some other part of my application, uh, some application state, like, Hey, this person just made a purchase and I need you to send that purchase to the factory so that the factory knows they need to make some shoes for this person who just bought. All right. No, that's good. Or to add another layer to that, um, uh, we, we, to be funny about it, us here at downtown central headquarters, uh, we, we're authorizing you to manufacture 5,000 pairs

of shoes. And at the factory, you would like to know, like that was actually them telling me to generate the shoes so that two weeks from now, I don't call them up and they're like, what do you mean manufacture 5,000 shoes? But you can verify that, uh, that a faceless command, so to speak, actually came from the right source. Exactly. And that's very valuable, right? Because we don't have to then have this crazy system of making sure that everything's signed and everybody's like talking to each other and, you know, because we don't like to talk to each other, but we can just, as, as, uh, as, as our, our friend Bezos says, communication is failure. So it's, it's, uh, it's, it's good not to have to talk with each other. Yeah. Cause if we can automate the process and make it just simpler for people to do their job, then it's a much simpler, uh, model. But, um, when you make these data transactions, then, um, blockchain providers started thinking of, hmm, I don't really have to, uh, well, there's two approaches really. So there's the open source approach of we should allow anybody to write whatever they want onto a blockchain and use application development practices to distinguish what they want to put in. And that would be something like Ethereum, which I'll come back to later because it's my favorite. But then if we talk about something like Ripple, which is a financial institution, transactional service that uses blockchain, or we talk about something like, um, R3's Corda, then we're talking about something that uses, um, this idea of, I should be able to put whatever data I want and have behavior that exists, um, on the blockchain, but you're not opening it up to developers and you're not opening it up to a wider community. So, um, Ripple based on the fact that they're keeping things confined, uh, not only allows them to refine their product more comprehensively on top of a blockchain,

but it also allows them to change out their blockchain implementation. So, um, their blockchain implementation doesn't use that GPU farming that we talked about where it's, you have to find a nonce value. That is just something that you would never know. Uh, they use proof of reputation where the more that a node has contributed and the more transactions that the node has signed that have been committed onto the ledger as valid, um, the more reputable they'll be. So if some new node shows up, anybody can join the network, but if some new node shows up and starts signing transactions left and right that conflict with one another, and they don't make sense, then people will eventually start ignoring that node. And it won't matter what they say just as a part of their reputation. They'll identify that. Oh yeah. Node number five over there. He's been yelling about some kind of nonsense for too long. So we ignored him. And that allows them to not have that latency of you need to find a nonce value. You can immediately, um, use your reputation to verify that the transaction that you're pushing is valuable. But remember that that's exactly what we wanted to get away from in our blockchain implementation. Because, um, you could theoretically just sign a whole bunch of transactions and then at the end of the day say, haha, I'm just kidding. I wanted to do this evil thing all along and sign something that's bad. Right. Right. So it's good for a private model. I think that Ripple has a very good blockchain idea for their model because they can ensure some sort of data security and integrity behind the scenes. Um, Corda operates mostly the same way, except they've started to move a little bit more towards application development where you are allowed to use their, uh, special execution environment to run an application that does verification of whatever, uh, data it is that's being written onto

the blockchain. So for example, they, they focus more on financial institutions. So they might have, say bank A and bank B bank A has some API that they can call from that execution environment that Corda is providing that will say, yep, that transaction looks good. I say that it's fine. And then they also have, um, another side of it that will ask bank B if the same transaction is something that should go through bank B might say, no, that doesn't look good. And so the whole transaction cancels. But if bank B says, no, that looks good. Then you've allowed both banks to provide their own value in their verification process. So that's getting a little bit closer to what we think of, um, as how you would use a distributed system in a replicable environment to process data, right? Yeah. It's a whole like, uh, uh, I don't know, sort of, uh, what do they call it? Like election sort of stuff when it comes to distributed data verification of having multiple nodes sort of weigh in if this thing is true or not. And then, and then obviously as maybe you're going to get into, there's all sorts of heuristics of how, if, if you trust that, uh, a yes or no vote from, from something. Sure. So I can, I can actually, um, I'll, I'll move back a second and talk about the lower level problem that both blockchains and distributed systems in general try to solve. And the problem is called the business team generals problem. I'm from, I'm pretty sure I just, uh, mispronounced that, but it's okay. So you're supposed to imagine three generals that are all encircling a command post that they intend to either attack or retreat from as they're encircling this command post. Uh, how do you verify whether or not they will attack or retreat? And we can talk,

um, for another, if you wanted to, we could talk for another three hours about how, um, I can always assume retreat until I hear otherwise, or I can always assume attack until I hear otherwise, or, um, I send somebody over, but they get killed. So I have to send three people over because it's much less likely that with that redundancy, everybody would be killed or intercepted on their way to general that I want to tell my information to. And so we get into this issue, um, where if we work out all of the problems, we basically need two thirds of the generals to be in agreement for you not to, um, fail against this attack. Because if two thirds of the generals agree, it's in the third general's best interest to, um, not lie and to play by the rules, just by how the, um, how the system would work. Where if the third general retreated and the other two attacked, they would obviously know that he was ignoring them. Right. Or if the opposite was exactly true, then they'd be like, uh, that's not good. Like you probably shouldn't have done that. Um, so we can run into this problem in a real scenario where, uh, if you imagine a, uh, I had this example up here with, um, NASA actually had this issue with a flight control system, um, that would fail given a certain small set of conditions that was considered out of specification. And because they never, um, designed a system against that potential failure, then the whole system would crash as soon as one thing got out of agreement. So it was as small as, um, an accelerometer could be potentially like halfway off what it should be. And everybody would like completely lose their mind in the system and everything would shut down. Right. Because they

didn't design with the thought process in mind that hardware might fail. And so we also should be planning for that kind of low level, um, nodes can be compromised and nodes can fail. And moving up from that is where we got to blockchain and where we got to these implementations. So returning to our example in blockchain, uh, the ripple is assuming that everybody's going to be reputable or that you can use the weight heuristics. Corda is going to assume that the external APIs are always going to be available and that the external APIs will always be reputable, which is, you know, you can talk about how reasonable that is based on what the implementations are. But my personal favorite is, um, both hyper ledger, uh, from IBM and Ethereum from the Ethereum foundation are moving more towards this idea of, uh, we should provide a platform for people to write their own rules on what should go into the blockchain and how you can access that data. Hmm. So now you can have this idea of these smart applications that are, um, always running in the same environment, no matter what node you're pinging throughout the entire network. So I can write one thing. So I say that I'm just going to publish my application onto the blockchain, and that's called a smart contract because it's basically, um, a contract that you're signing when you, uh, hit the blockchain and say, yep, I'd like to be a part of that. So the smart contract is like a big application that can be reproduced on any of the nodes throughout the blockchain. And I'm going to publish mine. And I'm going to say, if any shoe manufacturers would like to take these orders, this is what you need to do. And here's an endpoint that you need

to hit to say, you want to claim the order. Um, so then shoe manufacturers might check in and they'd say, okay, it seems like Gary has 5,000 shoes that he needs to be made. And I can continue to update that as I get more orders for shoes. They can then update in a reputable way using the blockchain technology and say, I'd like to take that order for 500 shoes. And then another person comes in and they say, I'd like to take that order for 1000 shoes. And we don't have this problem of double spending where too many shoes would get made because the verification process for blockchain is extensive and you would never have that issue using some kind of proof of work or proof of authenticity, claim. And then, um, you would have a record of everything that was said. So if the shoe manufacturer shipped me 50,000 shoes, when I only asked for 500, I'd be able to go back and verify that they said they would only make 5,000 and they would only charge me for 5,000. Right. Right. So, so like, like, like in this example, how, like, what are the usual ways that like all the, all the data in, in the ledger, so to speak is like distributed, right? So you just named three entities there, right? Who, who in theory have their own corporate networks and servers and all that stuff and stuff that runs their APIs. Like, like, are there just like hourly batch jobs that run that like, I'm sure they don't FTP, but that transfer like this data around and then you update your, uh, your own block, your, your sort of like local copy, so to speak of the blockchain, or like, is it always centralized somewhere or like, where's the distributed nature come in to, to that? So that's where, um, each of those big batches of transactions and nonce values and signed keys that give you that value. If we run back to Bitcoin, that whole data structure is called one block. So you would say all of those transactions exist in

that one block. And now that block is history. I can assume that all of those transactions have happened. And when you start your blockchain node and you use a blockchain client, then you are always operating off of the assumptions that that block has already happened. So based on the nature of the blockchain, you would always have the point where transactions would either be verified or ignored based on the previous state of the ledger. So if you see a new block that's higher number than the block that you're on, you have two choices. I'm either going to ignore this block and try to make my own version of the blockchain, which people will inevitably ignore because they see higher block numbers than the ones that you're producing by yourself. Or you can accept the new reality and build your transactions based on this new set of history. It becomes a problem of if you want to contribute, then you either have to have more power than everybody else to make your own set of block, or you can use the blocks that exist and that everybody's contributing to. And you can build on that version of history to make your application reputable. All right, I think that makes sense. That's the file system that you're talking about. That's that whole ledger is that those blocks, once they happen, you can't change them. Right. And, and, and so, so kind of, well, depending on the accuracy and ease of what you want to verify past events with your own, uh, with your own copy of the blockchain thingy, uh, you basically always have to be accepting the new, the new nonsense that are in the system and figuring out if it makes sense to add them to your own. And then, and then you, and so you could, if you were the manufacturer and, and you're, uh, you've got the two manufacturing companies, one wants to make 5,000, the other wants to make a thousand. And if your network goes down for a day, you'll have to spend some time going to those two, those two, uh, other manufacturers and getting

all the nonsense they've created and deciding whether or not you add it to your blockchain. But then once you do that, you can go verify, you can go see these orders have come in and verify that they were actually orders from, uh, from those two manufacturers. Right. So you would assume that all of the blocks participating in a certain chain would be sharing the same ledger. So both of the companies, both of the manufacturers would be using, um, essentially your chain and they could communicate between themselves as well that, you know, no, I got that order first. I got that order first. There's no argument. It's just whoever got into the chain first and who got the transaction in first. And you can do like timestamps inside of the transactions to make sure that whoever did what first actually did do it first. Yeah. Well, all right. No, I, I think that makes enough sense, but, and so, and so before we run out of time, so how does all this fit into, uh, into, you know, uh, things you've been doing in Cloud Foundry? Like what do you use it for in, uh, in a cloud platform like that? So we can, um, one of the things that we wanted to do was that apparently customers are having a problem being able to verify their operational state or the operational state of certain applications. And we built, um, just as an example for a POC, we built a distributed ledger system that's, um, running inside of a cloud so that we can, um, run that as much as we want and we can hook it up to something that's sitting in the backend to verify that, um, the IAS and that Bosch and that the cloud are all seeing the same thing at the same time. Oh, that's interesting. Right. And then that gets to the point that like in a, a fast, a really fast moving, highly distributed system with like multiple nodes doing things, you essentially want some way of saying like, well, most, all of these nodes think they're doing all right. And then therefore we can kind of conclude that everything is running at the, the, whether you want to call it service level objectives or SLAs or whatever, like they're all operating at a level that we find, uh, acceptable. So we don't need to try to fix the

problem that's going on. And then more importantly, um, we, we have, and it could be timestamped as well, but we have a verification that this is actually the, the state in, in the time that we want of all of this stuff. We can trust all of the, uh, the, the metrics that we've gathered about health. Absolutely. And the other side of it is, um, we're trying to deliver the value because everything that we just talked about, I mean, we've been sitting here for 45 minutes and, um, I'm pretty sure that it would still be difficult to get started on an actual like implementation. If you had an amazing idea just city of blockchain. So we're trying to give Ethereum, um, is our blockchain of choice at the moment. And they, um, we're trying to provide that as a service. We're trying to say that you can just use Ethereum and we will provide all of the backend awfulness that you don't want to deal with. And all you have to worry about is writing your application and making it work with a Ethereum node that could exist anywhere. So that's, that's the value that we're trying to deliver in, um, in our space so that we can kind of say, you know, go out and play with it, do something that you think is valuable with the application development that you're working on. And then this would, this would essentially be like a, a fully integrated, ready to use just service in a cloud foundry instance, right? So you wouldn't have to, uh, figure out how to package it all together and all that. You could just do the usual, like, you know, adding a tile or however people want to call it in their, their distro, but just on the command line, a product, an application team could just add it in and start using that service. Exactly. And we're still, you know, it's still, um, blockchain is changing all the time. So we're still at the development phase of, um, we should be using it to investigate potential sources of value and building on what we can. And it's very difficult to do that if you can't actually use the blockchain because it's too awful to set up. So if we had a Bosch release that would give you a blockchain that you could just use and you could scale using Bosch or with cloud foundry,

then that would provide value, right? Because then you have all of the greatness of cloud foundry and Bosch and replication and distributing across environments and different networks and availability zones and all of that. So, so then, then I guess to, to in, in my way, grossly generalize it, right? So you add in, uh, well, what, what, what do you, what do you guys, what do you call this? What's the name of this, this thing, this project or whatever? Uh, we're just calling it Ethereum as a service. There you go. So blockchain as a service. So if, if you have, if you have Ethereum in, uh, in your cloud foundry setup, the, the simplest thing, the simplest way of putting what it provides is a, uh, to use the word again, or let's say a verifiable log of things that have happened. Now, what those things are is like the next step. So you can always verify to say, I guess you can't verify that what was claimed happened, happened, so to speak, but you can verify that something, something, uh, something said that something happened, right? Uh, so, so a node on its own might've evaluated itself and said like, I'm healthy or something like that. So, so then what that means is you at least have two different things on the, uh, let's call it business capability front. However, you might want to use that. And we went over a few examples with our manufacturing thing, or just like a pure currency, or I guess bank ledgers would be another example, or, um, also the way that insurance companies keep their books or, or whatever. Uh, you could provide just as a capability for your application. We now have a verifiable ledger that we can use. However, you can think of business-wise. So that would be something you could do with it. And then the second thing that we alluded to a little bit is more of more or less like you could be providing a service that other people use to build applications, which is a whole other thing, but let's set that aside. But internally, you could use it as a way to verify things that are happening in your own cloud foundry instance. So we went over a, um, like a health check, right? Like at any given point, you know, we can verify that, uh, these nodes at some point thought they were healthy. And so that gives us a

sense of what's going on, but you could, I, I imagine you could also do other things that like, if you wanted to automate, uh, like deployments and you wanted to automate doing some canary deployments, you could essentially, the way that you would track. So a canary deployment being like, I always say the word node. I don't know what the kids say nowadays, but let's say you've, you've got 500 nodes and you want to, you want to roll out changes to just five of them and see if it worked. And then if it works, you're going to roll out changes to 20 more of them and then 50, and then finally to 500. And you do this incrementally so that you don't break, uh, too much of production. So you need some way of the more automated you want to do of tracking if anything was broken or not. And you could use the centralized ethereum, whatever ledger of verifiability to go in and check, like, were those first five nodes good? And can I trust that they're the ones who said they were good and the next 10 nodes and so on. And so you could have a central ledger of everything was hunky dory. And now we can, uh, we can roll out the change. And then I guess that has, that has another exciting side effect. If you're worried about like, you know, three ring binder ninjas of audit and compliance, you've got like a log of, of, of a, not only a log of events happening, but a log of a disciplined approach to something happening. Cause you know, compliance people in, in, in an overly nuanced kind of way, they're usually interested that you had a process and you followed the process and it's not really their job to worry about if things were successful or not. Exactly. And if you write it into a blockchain contract, exactly what you said with compliance. If I'm writing something literally called a smart contract, I can write a contract that runs code. And when that code is run, it is verifiable that it happened based on everything that we've covered. And then you can say, yep, I did exactly what I needed to do. And the rest of it is you can do whatever you need with the rest of the data. Right. And, and, and then on the extreme end, in contrast, I mean, as, uh, there's a great, uh, a great talk from, uh, uh, this guy, I think it

was, no, it was HCSC, this guy, Mark at a big health insurance company. And his point was, I mean, it's, it's sort of difficult, but like, you know, you can just write whatever you want in a log file and zip it up and send it to a compliance person. But one, it's very difficult to take all of your, you know, sort of, let's say your get, your get logs and your Jenkins logs and your PCF logs, like theoretically, uh, in the same way that theoretically with some paper, you could come up with nonsense if you lived long enough, but theoretically you could falsify all those logs, but it's very hard to falsify them. And then another layer would be that the only way that we're going to trust all this package of these logs that you're giving is if it's been, you know, it's participating in our blockchain essentially, and we verify it through there. So you have, you have as rock solid as we can hope for. I mean, there could always be some extraterrestrial entities that like operate under different ways that we don't, and we don't know about who are falsifying, uh, you know, the fact that, you know, George put this hat on a cat and then just the whole system would be flawed, but whatever. But as best as we can hope for with our current understanding of reality, we can verify that this thing, this thing, that this, that a system said this thing happened, uh, basically. Absolutely. And that system is distributed. It's not one computer. Right. Right. Exactly. Yeah. Well, that sounds good. Was there anything else you want to preview from your talk before we wrap up? Uh, no, I think, um, I think we hit all the major points and you're just going to have to be at CF summit if you want to hear the rest of it. Exactly. Well, before I wrap up, so if people want to, uh, catch up with you or like, just see what you're doing, like what, uh, what would you point them at over there on the internet? Uh, yeah, so I can give my GitHub. Um, I'm usually committing to a few rebotes in the EMC dojo, uh, repository there. So it's, um, just Gary P white. I am not creative at all. I didn't come up with something clever. It's just my name with the P in the middle. Well, it put, it puts you in the exclusive club of people who like to have their middle initial. It's very, very noble. Yeah. Well, it came out when I put

it on Facebook because there's way too many Gary whites. If you look on Facebook, there's like, Oh my God, too many. I bet. And you have a Twitter account or anything like that? No, I do not. Oh, very nice. Another exclusive club. I know. Don't bother me. And then, um, I can do, uh, I can do emails. I will, I am always checking my email at least once a day as a developer. I have the luxury of not having it open all the time, but it's just, um, it's all Gary P white at live.com. So it's the same as the GitHub handle, but it's just at live.com. That's right. So if, if, if, uh, you know, at Twitter, don't go knocking on your door cause you're not home essentially. Well, well, thanks for being on that. That was good. I feel, I feel like I know, uh, you know, maybe 10 to 20% more about blockchain, which, which is, which is not your fault of explanation. It's just that it's, it's a, uh, it's a complicated subject, but it's very, but that that's, that's infinite growth from what I knew earlier. So that's fantastic. 10 to 20%, you know, it's still zero. So perhaps so, but no, no, more seriously, that's, that's, uh, that's, that's good stuff. And so as always, thanks for listening. This has been Pivotal Conversations. If you want to get the most recent episodes without having to poke around in your web browser, whatever you just go, you can look around in your iTunes or your overcast or whatever thing you use, and just look up Pivotal Conversations and subscribe to the podcast and all the episodes will be downloaded. Now, if you prefer a slower podcast method, uh, you know, you're cooking your greens and you're waiting for them to cook and you wanted to live that slow provincial life. You can also go to soundcloud.com slash Pivotal Conversations, all one word and see all the past episodes and find a link to the RSS feed and other things like that. Get a sampling of what's going on. And then, uh, we lag in posting our full, full show notes, but you can see full show notes over at pivotal.io slash podcast. And then as mentioned earlier, if you're interested in this talk and, and other things in the cloud foundry and cloud native world. So we've got CF summit coming up. That's a June 13th and 15th over in, uh, I guess it's the Santa Clara convention center next to that big old Levi's stadium. I've

never verified if you can actually buy blue jeans there or not, that would be fun. Hopefully that's the case. I think they also do sports there. Uh, but you can go over there, uh, June 13th and 15th. And if you want to register, you can use the code CFSV17COTE that's C O T E, my name and you get 20% off. Now that's kind of a mouthful, but it's basically cloud foundry Silicon Valley 17, which is the year we're currently in last I checked. I might need to go verify that with some nonce or something. And then you just put my name at the end. And, uh, you can also check out the show notes, or if, uh, you're lucky enough to have a podcast chapters, if you open it up where I started yammering about this, you'll see that, uh, that as well. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.