Transcript: Blockchain for Collaborative Communities

It's the philosophy of using a blockchain for collaboration as opposed to simply adding another layer of tamper resistance. I think people can easily add that tamper resistance if they really want it. It's not hard, but they already have so much of it today and most enterprise databases, including the backups, jointly are pretty tamper resistant. If there is tampering, people will find out and they will spot it. But if you want a little bit extra, that's very easy to add that extra component.

I don't think blockchain adds the value there. I'm not saying do not consider blockchains. I'm saying expand the notion of why you're thinking about blockchains. Most people think about it, we are living in a trustless environment, we need extra protection. I don't think that's a valid cost value proposition in the enterprise.

But there is an aspect of the blockchain that people hardly talk about, but it is fundamental both in Bitcoin and in Git. And the fact is that both of those are peer-to-peer networks in which peers contribute significantly to the blockchain, not just to make it robust and tamper resistant. They actually contribute to making sure that the data you enter into the blockchain is valid. In the enterprise, look for situations where you can have blockchain in collaborating communities. So the peers are actually peers that can contribute to verifying the validity of the data.

So I think there's much more use in blockchains in collaborative communities. Hello, and welcome to the Constructor Podcast, the best way to build it, episode number 89. I'm your host, Brittany Campbell Turner, and this podcast is dedicated to helping property owners have certainty in their decisions about their construction projects. We talk about fostering trusting relationships, help you to understand how to lower risk, be under budget and on schedule, and most importantly, exceed your end user's desires. Last week, we spoke with Thomas Wendling.

He's an advisor to the Integrated Engineering Blockchain Consortium, professional systems engineer at Jacobs Engineering and co-founder at Co-Engineers, a blockchain engineering platform cooperative. I met Thomas through the Integrated Engineering Blockchain Consortium, IEBC, and we're working together to contribute to co-engineers. We spoke about co-engineers and how we're building a blockchain solution to build a network to measure that intrinsic value that engineers create, thus reducing risk for engineering solutions building a network of reliable engineers. We kick off that episode by talking with Thomas about the current state of infrastructure and the notion of obsolescence, a physical or capital property.

This is a lot of what he's working on at Jacobs Engineering. We also talk about co-engineers and the economic value model that can help to reduce risk by understanding the intrinsic value of a person who has a skill regardless of their background. If you haven't listened to this episode yet, check it out at constructor.com slash EP 88. So in today's episode, my guest is Efrem Feig, an IEEE Life Fellow, and he has a PhD in mathematics. He was the manager of signal processing and coding at IBM Watson's Research Center, and he is an inventor on 33 US patents, author of over 100 research publications and a plethora of topics, including blockchain.

So I invited Efrem on the podcast to talk with me about enterprise use of blockchain solutions. We talk about the notion of trust in collaborative working environments. We talk about the difference between the Bitcoin blockchain and Git and how the value of the Git blockchain can support a more collaborative working solution. We baseline on proof of work versus proof of stake, and we also discuss public or private blockchains. So with that, let's get into the interview.

Today we are talking with Efrem Feig. He is an IEEE Life Fellow and has a PhD in mathematics. He was the manager of signal processing and coding at IBM's Watson Research Center, CTO and CMO at Kintera, an early cloud company, senior director of services architecture at an associate CIO for vision and strategy at Social Security Administration. He's an inventor on 33 US patents and author on over 100 research publications. So Efrem, I'm so happy to have you on today.

Welcome to the Constructor Podcast. Thank you, Brittany. Thank you for having me. We talked about 33 US patents in the intro. I wanted to ask you, could you give us a couple of examples of things that we may be using on a regular basis that you've contributed towards?

A lot of my patents have to do with digital image and video and coding and decoding. So you're using them on JPEG and MPEG images and videos. I created fast algorithms for signal processing methods or video coding, what we call graceful degradation, various types of techniques in signal processing. My techniques sometimes come into use, sometimes go out of use because technology keeps changing. So for example, my fast algorithms, when processing becomes very expensive, they come to use.

And when people don't care about processing, they might go to other techniques. But now with IoT coming in again, processing again becomes expensive. These are constantly being reused. Another set of inventions have to do with hot video, we used to call it. That's linking components of video themselves become hot links.

So you can click on parts of video and then it takes you to different places. Just to discuss a whole different area, the techniques that I use for magnetic recording of data. I worked on disk drives. These have to do with various techniques for actually measuring and planning things and also for what's called buried servos so that the head can follow the track. Wonderfully awesome.

I'm sure we're touching them with having no idea that there's an engineering mind that has invented a number of these things that you've touched. Much less everything that we touch every day, there's quite a bit of integration and collaboration. And the contributions of many, many hundreds of others, incredibly good engineers. That's right. Today, we're talking with you about blockchain applications specifically for enterprise use.

And we're going to dig into the elements of different blockchains, blockchain networks and talk about the notion of trust. I'm really excited to talk with you about this today because many organizations operate as enterprises. Your perspective from what I understand is to incorporate small aspects of enterprise software applications and use blockchain if it's appropriate. So we've been talking about blockchain pilots, case studies and current applications for the AEC industry. We've heard all about the hype from bitcoins particularly.

But first of all, let me ask you what got you into the blockchain topic specifically for enterprises and why are you passionate about it? A year ago, I was working on various other projects. I was actually doing a lot of development myself. I was experimenting with what can one person do in today's IT environment? Because the IT environment today makes coding and producing viable products, software products so easy.

So I challenged myself to study what can one person do? After that, I decided to go back to pure research and I was looking for what's the hottest topic. And the hottest topic by far was blockchain. Everybody was talking about blockchain. So, of course, that's where I decided to focus.

And I spent a lot of time reading and studying and talking to people. I always do that before I start developing my own ideas. And I read Satoshi Nakamoto's paper, which I would say is probably the finest paper on blockchain that has been written so far. It's an old, old paper. It's the one that kickstarted everything.

Yet it's still my favorite paper. I highly recommend anybody who really wants to understand blockchains should definitely read Satoshi Nakamoto's original paper. Bitcoin, the only high part perhaps with Bitcoin is the price, the fluctuations of the price. But Bitcoin happens to be an excellent application for blockchain. It really fits the blockchain model.

A lot of other things that people try to put blockchain into, they're kind of trying to shove it in there. For Bitcoin, it was absolutely a natural place. That's why it came with Bitcoin. And with Bitcoin, it was not a lack of trust in all intermediaries. The sort of global lack of trust, the way I see it, came considerably after Bitcoin.

Satoshi, in his paper, he was concerned only about bypassing banks. And he's very clear about the role of trust, because even in his paper, he says that using Bitcoin, you will probably need some escrow service. And he's thinking about, suppose I'm buying something with Bitcoin, I got to get that delivered. I need some trust mechanism to get something delivered. He mentions escrow in his paper.

So he's not dismissing all trust. He's just bypassing banks. And then something happened. And all of a sudden, there's this great concern about total lack of trust, people just not trusting pretty much anybody. There is this great concern that records are going to be changed.

So you hear people in supply chains saying, we need the blockchain for supply chain because we're worried that somewhere along the line, supply chain records are going to be changed or that somewhere along the line with health records, people are going to change our health records. So we need to really, really add this tamper resistance for our health records so that they become tamper proof. Now, the reality is that your health records never change once they're in the database. They just don't. Nobody goes in and says, OK, I'm going to change that person's health record.

There are many, many mechanisms built in modern databases and backup systems that make it pretty much impossible for somebody to do it and get away with it. There are so many traps and catches that if you do it, people will notice it right away. They will flag it and they will take actions. Same thing with supply chains. Same thing with your bank records.

You're not going to go back to your bank records from three years ago and find that somebody actually changed the record. That's just not where the fraud happens. The fraud happens before the data gets into the record. In other words, the data entry itself is fraudulent. So somebody will lie.

You got this treatment and you never got that treatment. Somebody will overcharge it for something. Somebody will say this diamond came from this location, but it actually came from somewhere else. And he entered into the database. That's my first comment about trust.

I understand that. I talk to a lot of people and they're very concerned about this trust of records being changed, even though I don't see it happening. What I see a lot of what I'm questioning is people manipulating, for example, with financial data, people will manipulate prices of certain assets illegally. People will hack into accounts and get your user ID and password so they can withdraw from your account. But nobody goes into your account and change the data.

They will just withdraw from your account or they'll hack and get some information about you that you don't want the information seen. So those are very legitimate concerns. As we move forward, we will eventually get more and more comfortable with where the trust issues really lie and focus our attention on much more on where we need to focus them on. So for me, blockchains in the enterprise are much more about applications in trusting community. So it's really almost like the opposite of the standard mantra.

You know, you read my paper. I look at two examples is Bitcoin and the other one is Git. And one, you needed a certain set of secrecy to bypass some authority like the bank. And you also wanted to protect your identity. But the other one, which is a much more popular application of blockchain, is totally driven by trusting communities.

These are small communities of developers. They use it both for open source and for private development. Both of these cases, they're relatively small communities of trusting participants and they work together building up a blockchain. So I think these are the two models that we have to keep in mind. And when we look at enterprise applications, we have to see which one of the two or sometimes it could be something in between is appropriate for the particular application that we're talking about.

I think you gave us a really broad spectrum as to why you became interested in blockchain for enterprises and sort of the end to end dynamic that it relates to trust. You mentioned specifically Git and then the Bitcoin blockchain. You mentioned about how appropriate the lack of need for trust is appropriate for Bitcoin. I'm curious as to how do enterprises operate today and what kind of trust model is in place based upon those typical data structures? Let's take an example of supply chain.

Let's take the one that people are talking about a lot today, supply chain of diamonds. You get diamonds from mines. They move from the mine to some processing, people are cutting it, and then they send them to finishers. They send them to setters who set them and then they send them to retailers. And you want to track them all along the way.

And in particular, there's a lot of concern that especially in the early stages, these diamonds were called blood diamonds. They come from places that we want to do business with and not with places that we don't want to do business with. Yeah, there's a movie called Blood Diamond. I remember watching that a couple of years ago. So absolutely those who are not familiar go ahead and check that out.

It tells you quite a bit about it. It's a good movie. The first thing is we already depend on trust at the very first stage. Now we get a whole bunch of data. And typically, the way we used to do that is we used to put it on a supply chain application.

That supply chain application, if you wanted to make it robust and temper resistant, you would replicate that in several places. You'd have somewhat autonomous agents responsible for maintaining those separate copies of the database. And the likelihood of a majority of them all conspiring to give you a false record is very, very low. There's enormous amount of trust right there because there's going to be somebody out there that stands there and enters into the block chain. The following piece of data.

I'm here. I'm observing this diamond that I know to have been obtained from this mine. The other ones were saying we are observing this diamond put into this bin. It's heading into this truck that's on its way to this particular facility. So that's a very typical scenario in an enterprise application for which people are proposing blockchains.

So we're starting out with enormous trust. We're already trusting that one person or that group of people to give us correct information. And in fact, all the way along the supply chain, we're trusting that when that person sees it going into a canister, going into a truck, that the next place in the block chain, somebody says, I'm seeing this thing come off a truck and going to this next facility. We have no idea what happened in the interim. We actually rely on trusted entities all throughout the block chain.

And that's pretty much the way the block chain will work. The fact that it's in many, many different databases all over the world makes it very, very difficult, almost impossible to change all of them simultaneously. And if you want to add tremendous temper resistance, you add proof of work to it that makes it really almost impossible, cost wise, for somebody to cheat. But that's an added layer of temper resistance to data that we're assuming is valid data because we trust the people who are answering the data.

The same thing with medical records. We get medical records. We basically assume that the records that are entered are correct. Hopefully, if we find mistakes, we'll correct them later. But the basic assumption is you go visit a doctor, the doctor writes a report, you go get some tests, you get the tests back.

We assume we take it for granted. We trust the people inputting the data to put correct data into the record. And then we record it. And people who are proposing blockchains now want to record their data on an even more temper resistant infrastructure by deploying blockchains. How important is it?

Is that really where we want to spend our resources? That's a decision that companies make. I think a lot of times today, people will make that decision based on marketing desires, because it's very, very, very attractive if you say you have your solution on a blockchain. And it's also pretty easy for them to actually deploy blockchain solutions. It actually depends on who you're talking to.

If you talk to a vendor, they're going to make it sound like it's not that easy. So they can sell you the new software they have or the new systems they have to deploy it. If you're talking to a company who's processing the data, I don't want to say own the data. Medical records, one would think that the patient owns the data. But if you talk to Scripps or Kaiser, they would like to, as much as possible, retain the systems they have in place today.

They've spent hundreds of millions of dollars on medical record systems and processes. They work very, very well. And when you ask them to start thinking about blockchains, you can show them how they can just take whatever systems they have and add a blockchain layer without having to go through a whole new infrastructure. They like that much more. But their trust model is very different from the so-called trustless model.

They're living in a trusted environment. They trust their practitioners. They trust their caretakers. They trust their testing facilities. I love the examples that you gave regarding supply chain for diamonds and health care records.

And you're talking about the trust dynamic for each. Obviously, there's a question as to the environments that people are operating under, whether they're trust based or not. I really liked the idea of having, like, for instance, the diamond example. You specifically mentioned that on a typical enterprise that might be used today without a blockchain. It operates similarly where they have the database of information replicated in multiple locations so that if there's any need to do a second review, you can always compare against all of the records.

And they're all in multiple places, similar to how you would already do on a blockchain. So that makes it trustworthy already. And then similarly for health care, most of the time people will trust the records that are already made. In that case, are you proposing that the environments that many people are proposing for blockchain utilization might already have a built in trust mechanism that don't need a blockchain that operates similar to, like, say, the Bitcoin blockchain that has the notion that you don't need trust? I'm not saying do not consider blockchains.

I'm saying expand the notion of why you're thinking about blockchains. Perfect. Most people think about it. We are living in a trustless environment. We need extra protection.

I don't think that's a valid cost value proposition in the enterprise. But there is an aspect of the blockchain that people hardly talk about. But it is fundamental, both in Bitcoin and in Git. And the fact is that both of those are peer to peer networks in which peers contribute significantly to the blockchain, not just to make it robust and tamper resistant. They actually contribute to making sure that the data you enter into the blockchain is valid.

So Bitcoin, when somebody proposes a block of transactions, all the peers work together and reach consensus to agree that the next block of transactions are all valid transactions. So they're saying we are confirming the truth of that data. So we're not relying on any individual. They're all confirming it based on the information they have in their blockchains, which is wonderful because you can actually do that in Bitcoin. In the diamonds example, that's not the case.

You only have one person confirming the validity of a transaction. And it's not something that they even need the blockchain for. It's just an observation that they make. And no other peer can confirm that transaction. In the enterprise, look for situations where you can have blockchain in collaborating communities.

So the peers are actually peers that can contribute to verifying the validity of the data. So let me give you the example that I've been working on recently. I just wrote an article. It was called A Billion Blockchains for Healthcare. Yep, I actually have it open right now.

So please go ahead. Okay. In this vision, I'm really trying to copy both Bitcoin and Git. And what I'm saying is, first of all, what should the blockchain contain? The blockchain contains the information necessary to validate the next piece of information that comes into the blockchain.

So I'm saying to myself, if I'm looking at my own health records, I don't need the health records of somebody in Cincinnati unrelated to me. So why would they be on the same blockchain? It's just access baggage. I'm envisioning a blockchain for each patient. Now, that blockchain might have information also related to close relatives, because you might need that historical record, genetic data and stuff like that.

But it's basically a personal blockchain giving you the state of the health of that individual at any given time and the historical state of health of that individual, which is useful to know. Now, how would the peers come in? Well, the peers would come in as you're adding the next block of data. That block of data, just like in a Bitcoin case or in a Git case, would be pending for a while until some of the other peers might look at it and may or may not add contributions before they decide, okay, let's add that onto the record.

In typical cases, that will mean excessive work. Usually you don't have multiple doctors reviewing a record. But we're getting very close to the point where we can have autonomous AI agents as peers. So you can have artificial intelligence systems operating as a peer on a blockchain. And as somebody answers the data, they scan that data and they know the person's history.

They have it all in front of them because they have the blockchain. They have their entire history of that person's medical records. And they can make some remarks like, well, you might have missed this thing, or maybe I disagree with you here and you might consider this. Basically, they can actually act as peers, genuinely as peers. Ultimately, because that's the law, the person in charge of the record, the doctor typically, will look at the peers' input and decide whether to keep the record or amend the record before making it final.

So real use of the peer-to-peer nature of blockchains, the peers are actually contributing. I can also envision if you have remote medicine in some places very far away from good facilities and somebody needs the input from some doctor who's an expert somewhere far away, they put in a record that's pending, the other doctors who are experts might review it. And then there is a decision, a consensus. And then that record becomes the next record on the blockchain. So I envision blockchains in the enterprise much more collaborative tools than tools that hide identities and protect tampering because the tamper resistance is already built in most systems.

And the techniques people use are very similar to the blockchain techniques. They're all the same cryptographic techniques. They're all the same redundancy techniques. They don't spread them to a thousand different places. They'll spread them to four or five different places.

Nowadays, replication gets cheaper. They can spread them to ten different places. That's tremendously robust. So I think there's much more use in blockchains in collaborative communities. I'm really happy that you've said that.

Over the period that I've been studying blockchain, it really has become apparent to me that, especially in the AEC industry, architectural engineering and construction, the dynamic of the participants in a project or a program to execute design and construction, they will be working collaboratively. They will already know each other and they will already have had a trust based relationship. And I think that there is a way to develop a more collaborative relationship by utilizing blockchain and getting to that validation process that you're describing, getting to the point where you can trust the information simply because it has been reviewed by the people that you've already entered into a relationship with.

It's refreshing actually to hear you say that because they can be used so much more as a tool to promote collaboration and communication in a trust based environment. Let me add a couple of things. One is just philosophically, I'm much more comfortable in the enterprise dealing with trusted peers than in trustless environments. Typically, people will not go into business with people that don't trust. It's just much more of a natural thing.

I think we're going through a phase. I think people are very disillusioned. They've heard so many different things. There really is some lack of trust that's happening. I hope it doesn't last too long.

I mean, it's always good to be skeptical. It's always good to protect your privacy and protect your assets. But if you're going to be doing business with certain people, you will be collaborating. And besides, like the example I gave with the diamonds, you're going to rely on trust anyway by selling the point that you're adding resilience for trustless environments, maybe you're over building confidence that's not there. Maybe people will be more relaxed about the trusted components because they think they're so protected already by blockchains.

I've heard terms like in blockchain with trust, the truth machine and things like that, that might give the people a false sense of security. And it's just more philosophically comfortable for me to have enterprise applications running in trusted environments. The second point I want to make is that if you look at all the trustless environments, and those are the cryptocurrencies and tokens that people are doing. And here's the interesting thing. All these things depend on certain software that runs in the background that nobody knows what it is.

Very few people know what it is. That's open source software almost always. And we trust that software. Why? People say, well, it's open source.

Well, just because it's open source doesn't mean a lot of people are looking at it. I mean, most open source projects are three or four people working together. Fine. All these new current tokens that people are doing now that are coming out, they're just a few people working on it. There's really not too many eyeballs looking at it.

You don't know what kind of holes it has, what kind of security flaws it has. And yet we're constructing these software applications to combat trustless environments. But we're running the software that somehow we're trusting. And even more ironic, all this software is created using Git, which is a blockchain that's running in a trusted environment. So in Git, the peers are not unknown.

We all know who they are. They typically give their name or their pseudonyms. They're well known. You know who your peers are. You talk to them.

You collaborate with them. You don't accept their input right away as next blocks. You discuss among yourselves. So we're using collaborative blockchains to build blockchains for non-trusted environments, which I find very ironic. It is very interesting, isn't it?

Even the biggest projects like Bitcoin, in its entire history, since it was first put on GitHub, I checked today, there were 553 contributors throughout. And in 2018, half a year now, there have only been 40 contributors. So we're trusting this huge, massive piece of software to a relatively small set of contributors. EOS, which just went public with a $4 billion ICO, which is mind boggling, has only had 134 developers. That's not a large number of developers.

And yet people trust it. They give them their money. They give them billions of dollars. Those are great examples. Glad you're mentioning them.

So let's talk about your definition of a blockchain and a blockchain network. I want to establish that for myself, but also for the audience, because I think it's really helpful to just lay the groundwork again. I try to separate the data structure from how we use the data structure. I did that in my framework paper. I define a blockchain as a data structure.

As a data structure, it's a chain of blocks or a sequence of blocks that are chained together cryptographically. That's why we call it a blockchain. So it's a sequence of blocks, and each block is linked to its previous block using some cryptographic techniques. We can go deeper into it, but I think that should basically describe what it is. It's a sequence of blocks of data, but they're linked cryptographically.

So if you change something in any one block of data, if you want to maintain it as a blockchain, you will have to change everything else. A blockchain network is a peer-to-peer network that maintains that blockchain, and it does so using a certain set of procedures. It does so by having some mechanism for generating a block, some mechanism for the peers validating the block, and some mechanism of consensus that the peers will all agree this is the next block on the blockchain. So the blockchain network is a peer-to-peer network in which this sequence of events is happening.

So some users input data, some peers, through some process, create blocks, usually one block at a time. Then the peers validate that the data is correct in that block. Actually, in most applications that we see, we don't know that they validate it's correct. In Bitcoin, they do validate it's correct. But for example, in Git, you cannot really validate that it's correct, but they validate, for example, that it doesn't crash the code in their environments.

They validate it's the kind of thing they want to see. They validate it, and then they reach consensus that this is the block they want to add as the next block to the blockchain. So that's the difference between a blockchain and a blockchain network. Yeah, that's clear. Well, it might be clear, but believe it or not, there's tremendous misconception...

Okay, go ahead. What really happens with a blockchain? Let's say you have the diamond blockchain. Now this data is on a blockchain. I go to the diamond store and I want to buy a diamond and the person, they give me a URL and that's the URL to the blockchain.

And they say, see, this is all the data. You can see all the data there. Now you can trace all the history of the data. And again, I have to assume that the data that was entered is valid data. I'm just trusting the people who entered the data.

Let's make that assumption. The blockchain is assuring me that that data has never changed. Well, that scenario should not assure me of anything. Number one is, I don't know where that URL is taking me. Let's say I go and download an app that thousands of people have said this URL is valid.

Okay, now I feel very comfortable. Thousands of people have said that this is a true peer that's holding a copy of the blockchain. Now I'm looking and here's where the confusion... People think if I'm holding a copy of a blockchain, then that copy cannot be tampered with. And that's false.

I can tamper with a single copy. So if I rely on a single copy, I'm not getting the benefits of a blockchain. I have to do a lot more. Typically I could get, say, the hashes from 10 different blockchains and if they all agree, then I'll go to any one of them and I'll take the data. Then I'm comfortable.

But again, I still need a plurality of blockchains to confirm that what I'm seeing is accurate. But even if I do that, that's not good enough because the person could have kept all the hashes correct and just change a piece of data without redoing the hashes. I would have to go to that blockchain and then compute several hashes moving forward. And depending on the kind of proof they have, I might have to go either a few to feel comfortable or I might have to go through the entire chain.

But I would really have to compute a bunch of hashes. Or what I could do, which I probably will do much more conveniently, is go to hashes of the blocks themselves, not the ones connecting the previous blocks, or a bunch of them, and then look at the data from those things and if they agree, I feel comfortable. In other words, just because something is on a peer's blockchain does not mean that thing has not been tampered. So if I was selling you a diamond, if I knew you were looking at one particular source, if I could change that one diamond information, I could behave very badly.

I don't think people understand that. I think people think that if it's on a blockchain, then every copy has got to be perfect. That's really helpful to clearly identify that may not necessarily be true. Either there could be human error that's baked in there, or it could be fraudulent activity, you know, somebody lying. But the information could be existing for a while.

But in addition to that, someone could change that one copy. And unless you really do that real deep investigation, then you're not going to know. The app that you have that you rely on does that automatically for you. And then if you have enough people confirming that that's what it does, you sort of feel comfortable that that's a good app. So it's more around the consensus, the people that are agreeing or doing the validation that causes the information to be trustworthy versus the fact that it's on a blockchain itself.

Is that correct? In terms of the actual data, you can have consensus on garbage data. Okay, fair. If there's no ability to determine whether data is valid or not, people will still reach consensus and the consensus will be this is the data we have seen and we agree that this is the data we're all going to enter on a blockchain. So it's not going to buy you much.

But ideally, some applications would have some ability to reach consensus, not necessarily with all of the peers, but perhaps a few of them. So you have more confidence. Still something to wrap my head around. And I'm sure the audience feels the same way. It's definitely helping to paint the picture for sure.

It is not the way most people think of blockchains. Definitely helpful. And I want to ask the question now around the proof of work versus proof of stake models. If you could explain how that differs. Biggest difference is proof of work is incredibly expensive.

Anybody who thinks that Bitcoin transactions are very inexpensive is misguided. Recent estimates is that a single transaction in Bitcoin costs more than 1000 kilowatt hours of electricity. That's an incredible metric, especially for the constructor audience who often is interested in sustainability energy standpoint. It's an unimaginably high cost. The person who's transacted today doesn't feel it because they themselves are not the ones who are paying it.

But we as a society, we're all paying for it. We're jockeying up the price of Bitcoin and we're giving it to the miners. Somebody's paying that cost 1000 kilowatt hours of electricity per transaction. Proof of stake is on some level a trust mechanism. You trust that somebody who's got so much money in the game is not going to be willing to lose it.

The more stake you have in the game, the less likely you are to cheat. You have other costs. You have cost the fact that some people just don't have enough stake and there'll never be participants in the proof of stake. So it's not a very democratized system. In that case, could you share with us a little bit about the escrow component of proof of stake?

There are different mechanisms, but basically you put some amount in escrow and if validating dishonestly, you will lose that escrow. Each peer is supposed to validate accurately. And if you validate something inaccurately, and I'm not aware of what the mechanisms are, if God forbid anything happens accidentally, but if you're not going to play by the rules, you will lose your escrow. Okay. So it's set aside for you essentially.

But if you're not acting honorably, it will not get distributed to you. You'll lose it. Basically you have to have certain amount of coin and you put that coin in escrow. So it's restricted. You can't use it.

And if you don't play by the rules, you will lose it. Okay. So how does that specifically relate to how Git works then? The term proof of stake in Git is something that only I use, but it's a different type of stake. It's your reputation as opposed to an escrow account.

In the block header, there's always the actual design, the proof and the proof of stake with an escrow, you sign your cryptographic identity. In Git, your pseudonym, the name you use for the project. People want to participate because they want that code to work for them. Throughout the discussion, you've been saying that Git is more appropriate for enterprise applications. Could you tell us as to why that is?

It's the philosophy of using a blockchain for collaboration as opposed to simply adding another layer of tamper resistance. I think people can easily add that tamper resistance if they really want it. It's not hard, but they already have so much of it today and most enterprise databases, including the backups, jointly are pretty tamper resistant. There's tampering. People will find out and they will spot it.

But if you want a little bit extra, that's very easy to add that extra component. I don't think blockchain adds the value there. I think the value of blockchain is what the peers contribute. That's what they do collaboratively. That's what they do with Bitcoin.

They contribute by verifying that the data is really correct. And that's what they do with Git. The reason I think Git is slightly more appropriate is because it's not that strict. It's much more forgiving. There's no need to hide everything and God forbid you lose a password, you lose everything.

The more cryptographic passwords you've got to carry with you, the more chances are of hacking. And we see that. We see a lot more hacking with cryptocurrencies than with regular banking. I mean, we see tens of millions of dollars lost pretty frequently. Now people are worried about the other financial shenanigans, but cryptocurrency does not take care of that at all.

In fact, we're already seeing the other shenanigans happen with cryptocurrencies. They're already creating derivatives. There's already a futures market for cryptocurrencies. So all the things that people are really worried about, the things that create gyrations way beyond the gyrations that we see today, all these derivatives and all the exploitation that has nothing to do with the transfer of funds to other coins, those are external to those and those are going to happen with cryptocurrencies and anything else. If you think of Bitcoin also as a collaborative environment because the peers are collaborating, it's just that they're collaborating for one purpose only.

They're not collaborating to make things more secure. They're collaborating to avoid double spending. Satoshi's paper says everything else we have in place, we can make it secure, but we need to solve a double spending problem. That's why we introduce the Bitcoin blockchain. There's not much double spending problems with many applications.

That's because most applications do not have so-called irreversible inputs. If you put something wrong, you can change it. It's not such a great damage. What I'm thinking through now is the notion of public versus private. I think what you've given us by talking about that original enterprise setup is that discussion of trustworthiness within an enterprise already.

Is there some further clarification that you can give us to define what is public versus private? I'll say private and permissioned are similar, but please give me some clarification on that. As anything with terminology, it depends on how people use it. A permissioned blockchain, two actors in the blockchain, they're the users of a blockchain and then they're the peers, part of the peer-to-peer network that are maintaining the blockchain. Many times the peers themselves could be users.

A permissioned blockchain, the two sets of permissions. One is you can give peers certain permissions and you can give users certain permissions. If it's a public blockchain, everybody can see it. Certainly users can see everything. If the blockchain accepts input from users, then a public blockchain would allow every user to input data into that blockchain.

Private blockchains are typically blockchains that are kept internal. Again, the question is what is kept private? Sometimes it could be that the peers are all internal to the organization or to the group of organizations that are working together and they will allow users to see it or they'll just restrict also the users. I can make peer-to-peer activity permissioned, but let users see everything. Those are my definitions for public and private and permissioned and not permissioned.

In Git, for example, the open source code is public blockchain. Git is half of the repositories are open source. The other half, it's approximately 50%, are closed repositories for software developers by people who pay. Well, typically it's used with GitHub. So they pay GitHub a monthly fee and they keep it closed.

But even in these open source public repositories, not every peer has permission to do everything. Certain peers can only read data out, pull data and make suggestions. Some peers can actually have permission to accept incoming blocks and new data blocks in the blockchain. So there are permission even though they're public. Let's talk more about Git.

I think in the publication that you wrote and I'll post both of these. Actually, I'll post all of the publications that you've mentioned thus far. We need to definitely dig into Git and I'm glad you mentioned that as it relates to the different types of permissioning. When I hear Git, I think of Wikipedia, for instance, and tell me if I'm totally off. That's what I'm thinking of.

Lots of people can contribute to this definition of something. Is that a tangible example of what Git is? It has a lot of similarities. But Git is considerably more controlled because you're not adding just text. You're creating every Git repository is a particular code.

And you're typically creating an application like Bitcoin or EOS. There are actually probably 60 million Git repositories just on GitHub alone. Half of them are open source. So similar concepts but not the same. It's as if people can contribute to the code for an application.

Anybody can come into Git if it's an open source repository and anybody can look at it. Anybody can pull data out of it. In fact, anybody can copy the entire Git repository and create a whole new application starting from whatever stage of the history that person wants to and continue from there. It's available for everybody to take. But as far as contributing, there are roles and permissions.

There is typically one allocated to several Git owners. And they have supreme permission to even completely kill the project. It takes a lot of trust building before people will give you commit authority to the main branch of a Git. Some stranger coming in and saying, I want to get involved. They're going to say, OK, take the code and then submit it to us and we'll check it and we'll see if we like it.

Over time, if people gain trust in this person, they will add that person, perhaps, to the group can actually add to the main body of the code. They want them to go through that vetting process. That makes sense. Yes. I think your Wikipedia example is a wonderful example, but just add a lot more constraints to it because you're dealing with a piece of code that's, if you put some false information in Wikipedia, it might last up to three, four weeks and somebody will find a correction and say, OK, this is wrong, I'll correct it.

But if you put in a piece of code or if you have somebody putting some really sinister backdoor things in a piece of code, you can cause a lot of damage. People are a lot more careful in developing code. That makes more sense. And so GitHub, what is that in a relationship then to Git? And I know that there are many companies like a GitHub, but GitHub is probably one of the most popular.

Git is actually was conceived as a peer-to-peer network application for what we call software source control. It was actually started by Linus Torvold, the same guy who did Linux, and it was started quite a lot later. I think he started Linux in the early 90s and this was started in the mid 2000s. And it was created to develop the Linux kernel. So it was created as a peer-to-peer network application, but very quickly, everybody started using a central repository, primarily GitHub.

So even though you could use it as a peer-to-peer application, people are very comfortable storing it on one central repository. Everybody's using it, including Bitcoin and Ethereum and all of that. It was very recently that GitHub was sold to Microsoft for quite a bit of money. Just curious as to what your thoughts are on that. What people write and talk about is that perhaps Microsoft is going open source, maybe even wants to put its operating system open source.

It's a possibility. I'm certainly not aware of it. That's just what people write about. I think a very good reason for Microsoft buying it is for data mining. It's a gold mine.

It's a gold mine. Now you can mine some of it now, but if you own it, you can do so much more. So Microsoft now has introduction to all the greatest developers. They know exactly what they're looking at, what they're trying to build. They're getting a picture into the future.

Now remember, GitHub is 50% open source. The other 50% is money-making machine. It's not open. I think they'll be much more careful with mining that kind of data because it's supposed to be private. But certainly just in the open source environment, they can get a much deeper look into where things are heading because they're seeing millions, literally millions of projects being developed.

They're seeing the best developers. They're seeing where they're going. I think for them, it's a gold mine. Very interesting. It makes a lot of sense what you're saying, for sure.

So GitHub is the central depository for the peer-to-peer network that's Git. To really answer the question that I have as I'm starting to think about, okay, well, what's the framework to set up blockchain? We want to understand what the dynamics are of a team that is already a trust-based team. What is a good set of questions for a developer, or anyone who's trying to think through the dynamics of how a blockchain would be working for an enterprise? So I proposed 10 questions you should ask.

Number one is who are the users? You'll have some usage in mind and you'll have to identify who the users are. How do they use it? Number two is what data do the users input? The blockchain is a database, blocks of data.

What data do the users input into the blockchain? The next question, are any of the inputs irreversible? In other words, are you going to be dealing with something that if you make a mistake, you'll be very sorry for it and you'll not be able to do anything about it? Or are you going to be doing something that if you do make a mistake, it might be a little unpleasant, but you can take care of it later? The way I see most enterprise applications, their inputs are not irreversible.

It's not like losing a Bitcoin. The fourth question is who are going to be the peers? You're going to be running a peer-to-peer network. Who are the peers? Is it going to be anybody who wants to join like in a Bitcoin?

Is it going to be people in your industry who are working together? Who are the peers themselves who are maintaining the peer-to-peer network? Question five is how do they create blocks? What does a block look like? How do people create blocks?

After that, number six is what do the peers validate? Do they just validate that this is a block I see? Or can they actually validate that the data in the block is accurate? Or can just some of them validate something about the data whereas others can't? Could they validate that I'm not 100% sure if it's accurate, but it has these properties that are alike?

In other words, what can the peers validate? And attached to that is number seven, how do they validate? What is the actual mechanism for validation? Before you move on, could you give us a quick example as to how to validate? In Git, I want to validate that the code makes sense.

The first thing I do as a participant in a Git environment is I run the new code, that is the code with the additional new block of data, which is an extra piece of code or some changed code. I run it on my environment. Let's say I'm running it on a Mac machine. I'm validating that this thing did not crash my system when I ran this using these tests. Somebody else might be running it and say, I ran it on a Windows environment and it doesn't crash that either.

Different peers might validate different things, but jointly we're validating that it runs in deficiently many environments that we're comfortable that this thing runs correctly. Something else that we might validate is, yes, this is a feature we like. Or some peers will go, even though it doesn't crash the machine, this is absolutely not what we want, so we will not accept it. There's a little bit of taste there also. There's some subjective reasoning here, not just objective stuff.

Happens all the time. Some designer, you might be building something and you're collaborating a design. Most of the people are saying, no, even though this design works and building will not collapse, everything is correct from an engineering perspective. This is not what we really want. You will not accept that.

Wait for an alternate submission. I think that's really good. I really appreciate you giving those examples. I'll let you continue with the questions that a developer should be asking. Question number eight is how do the peers reach consensus?

In the blockchains that we're all familiar with, the consensus is automatic. Like with Bitcoin, it's the longest chain. That's not necessarily the optimal consensus for many enterprise applications. In certain applications, you might want to have unanimous consensus. You might want unanimous consensus, at least a quorum of peers.

A lot of times with medical records, you might want... I was talking with some group, they want to do certain certification, and peers validate whether you've earned that certification. To do that, they would like a unanimous consensus by, say, three quarters of the peers. There are various different mechanisms for reaching consensus. Number nine is, is the blockchain immutable?

Everybody hears about the blockchain being an immutable record. You might not want a blockchain immutable, especially with some of the privacy laws that are coming into play. You don't have to have blockchains immutable. As long as you understand what you're doing, you might allow people to remove things from the blockchain because you might have to buy law. The last one is, how are peers incentivized?

In the enterprise, they're usually incentivized with salary, bonuses, their usual mechanisms. With Bitcoin, we incentivize them with block rewards and fees, the various mechanisms, but you have to take them into account. So those are the 10 questions that if you can't answer those 10 questions... Yeah, you have to get clear on all of those components. In fact, when people propose blockchain solutions to somebody and you're reviewing that proposal, if they can't answer those questions, you have to be a bit skeptical because they might be proposing something that uses cryptography and does a lot of nice things, but they're not really proposing a blockchain.

They're just using the word blockchain because it sounds good. It's a good marketing tool. So in that case, there are opportunities where something can be built that's a blockchain and also something that may not be a blockchain or could have a number of components that are similar. And you mentioned earlier that it appears that people are really trying to find a problem to use blockchain as a solution, even though it's not necessarily needed. My question to you is, for people who are interested in the technology and interested in leveraging it, what are your recommendations?

Well, the first thing I would say is, can you live with blockchain as a data structure replicated in, say, six to 10 places of which several of them are, I would call, independent disinterested parties? So it's resilient. So they're not collaborating to cheat because if you do that, then you're really robust and you have pretty much all the temper resistance that you're going to get from blockchains, deploying them fully as a blockchain network. That's a good starting point. If you can benefit from just blockchain as a data structure that's replicated sufficiently many places in a robust manner, you could do that really easily, starting with pretty much most modern database driven applications today.

If you want collaboration capabilities amongst peers so that you have data that's kind of pending before it's accepted into the blockchain, then you might consider a full P2P network of blockchains, but then you have to be very careful. You understand how these peers collaborate. Different peers might collaborate different ways. You have to design it depending on your business and your application. Those are really good.

What I didn't get the opportunity to ask you earlier is what you're doing. And I want to just have you talk about how you're helping companies establish, if it is appropriate, blockchains and blockchain networks for their processes. My role is right now mostly as an educator. I show people what they have in place today is already very close to a blockchain as a data structure and how they can get to a full blockchain as a data structure with what they have today. One of the ways I show it is in an article that I wrote, which relates to backups.

So people do incremental backups today. Each incremental backup could be thought of as a block in a blockchain. Incremental backups today have appropriate headers and hashes so you can check each block validity as you distribute it, because that's how distributed data is always checked. And you can add one extra hash linking a block to its previous block. And all of a sudden you have distributed blockchain as a data set, which is very robust.

You could do it even more directly on the database by adding certain columns to certain records on the data that you want to comprise your blockchain. That's a technical thing. But the two primary ways that I know how to take most existing database driven applications and create blockchain as a data set, and then have it replicated in ways that can offer robustness. There are other things you can do beyond that that has to do with creating sort of like notary services so that you can just take your headers and put them on a whole separate blockchain.

This way you don't guarantee recovery of the data. But if there's any tampering, people will know it. It'll be notarized and be out in the public domain. If anybody comes and says my data has been tampered, a company can prove no, it hasn't. So those are things that companies can do immediately to take advantage of a lot of the blockchain capabilities.

If you want to tokenize, that's a whole different thing because people kind of understand that. A lot of people will tokenize even without blockchain. Bank of America is creating coins. I guarantee you that coins are not blockchain based coins. They're just instead of points now they're going to call them coins because that's what sells.

A lot of people have been using incentives like points, coins, credits. Nowadays they're called tokens. You don't need them on a blockchain, but if people really feel that they need this tremendous added security for the tokens, airlines give you mileage credits, mileage coins. People really feel they need them on a blockchain. Well, I guess the airlines will put them on a blockchain.

So I think a lot of companies will just call them coins in the future and we'll see where that goes. Some tokenization might work. Our economic social model is changing. I am working with one company that I like a lot. It's Rios.

They are doing a Rios token. They're trying to enable content creators to better leverage their content and have more direct seen how it's monetized. They're building on top of the Ethereum blockchain. And you can see it firsthand with the content creation. Things that are totally digital, you can get a handle on because people can actually verify.

If I don't have to say I saw a diamond going from a mine to this box, I don't have to say I took this guy's temperature or I looked at her wrist and I saw a red spot. Those things are not digital, but anything that's pure digital, it's much easier to envision using blockchains because peers can actually verify digital stuff. Yeah, exactly. The notion of attributing an attribute for blockchain to a physical asset, that's something that obviously is intriguing, but it's always a little bit hard for people to understand and grasp.

Now, if I hear somebody's song and I get that and I put it on a blockchain before that person puts that on blockchain, that's hard to verify that I wrote that song, but that's a separate issue. That's fraud again. Yeah, that's exactly it. Well, maybe artificial intelligence in five years will say, no, that doesn't sound like your style. That gets to some other issues.

This is true. Yeah. Well, thank you for sharing about what you're doing and some of the projects that you're working on, Rios. Lastly, thank you for chatting with me today. I think this has been a clarifying discussion.

We've talked about a lot of these topics in other interviews, but I wanted to hear from your perspective and really get a baseline layer again. So it was really good to hear those. So the last thing I want to ask you is what are the best ways to contact you and learn more about what you're up to? I'm the only one in the country, I believe, with that name, or maybe in the world. If you Google my name, you'll learn a lot.

You can even email me, ephi at IEEE.org. I'll go ahead and put your email in the show notes. I appreciate your time and your contribution, Efrem. Thank you. If you want to learn more about Efrem FIG, check out the show notes at Constructor.com.

If you learned something valuable in this episode, share it with your colleagues and friends. You can also let me know you enjoyed our discussion by connecting with me on Twitter at Brittany underscore CT or find me on LinkedIn. You can always email me too at Brittany at Constructor.com. That's B-R-I-T-T-A-N-I-E at ConstructRR.com. In next week's episode, I'll be speaking with Amy Wan.

Amy Wan is an Esquire and founder and chief legal hacker at Sagewise. She's also the founder and co-organizer of LegalHackers LA and served as a Presidential Management Fellow. So in our interview, we talk about how Sagewise aims to build a dispute resolution infrastructure for smart contract disputes. We talk about Amy's thoughts on the future of smart contracts, responding to more enterprise needs. We also talk about private versus permissioned blockchain and being more flexible in the building and operating of smart contracts.

So with that, I'm looking forward to sharing that interview with you next week. If you haven't already subscribed to the podcast, you can do so at your preferred podcast player. Do it now. Please leave a review to show your support and let me know you're enjoying the podcast. I look forward to talking with you next week.