104: Blockchain Development with Chris Martin

Hosted byJoe LaSala

June 28th, 2018.

In this episode, Chris Martin of Type Classes and Joe LaSala of The Frontside talk about blockchain development.

Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at contact@frontside.io or on Twitter at @thefrontside.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

TRANSCRIPT:

JOE: Hey, everybody. Welcome to Episode 104 of The Frontside Podcast. I'm Joe LaSala. I'm a developer here at the Frontside and I'm going to be hosting today's episode. Today we're going to be associating blockchains and other cryptographically secure technologies and everything that has to do with the web and the future of the web. We have with us Chris Martin and he's currently with Type Classes. What do you do over there, Chris?

CHRIS: Our goal is to teach functional programming with Types, specifically with Haskell and a little bit Nix. We do subscription video service.

JOE: There seems to be, I guess a bit of an overlap between people who are into functional programming and people who are involved in this new space that has opened up, this new web, I guess and that's something that I want to talk about based on a tweet that I saw you made recently. You mentioned that there's a big section of the Haskell community that is being drawn into whatever the hot ICO is at that moment there, something along those lines.

CHRIS: Some of it are bitcoin people or something else but there's definitely a weird overlap that I can't fully explain.

JOE: It seems like strange bedfellows, right?

CHRIS: Well, there's a couple of things that make sense, which I think the distributed systems in cryptography are kind of these notoriously hard problems. I think when somebody wants to convince their boss that they really need to use Haskell for this problem, I think they can make a persuasive argument in this case.

JOE: That's interesting. There's actually, a lot of technology around blockchains around bitcoins, specifically being written in Haskell. I didn't know they were technologically overlapped like that. I guess I just thought they were two very kind of passionate communities but you're saying that a lot of the bitcoin startups that you might see coming out in any given week are actually being written with an eye towards functional programming. Is that accurate?

CHRIS: I don't know about bitcoin along this bit but I think some of the people who are working for banks and trying to develop their own sort of novel internal blockchains and stuff, I think those are the people who see this. Although in the case of banks, we don't necessarily see what's coming out of them, so we can't verify whether they're actually shipping things or not.

JOE: Yeah. That means there's a lot to touch on there. I would agree with you on your initial sentiment, also just to extend to say that I think personally that both communities are really evangelical. Functional programmers, people who are into functional programming, for me it hasn't clicked yet and I know that it will come into my heart. I've asked functional programming to kind of where things are starting to fall into line where I'm certain to see the world in that way but for people who have seen the light fully, I'm sure believers once monads and functors kind of enter the conversation. They don't leave. It’s similar like when bitcoin first started and everybody's running about the gold standard. Really, it's just nothing. It was hard to find resources on it that did the most of the amount of screaming.

CHRIS: Yeah, you're absolutely right, that culturally, they're going to attract the same group of people or the people who are willing to adopt something that's not fully fleshed out yet, people who want to take what they believe and sit in this community and try and spread it to the rest of the world. I think it's the same kind of people.

JOE: The early adoption, I think is something I can consider too. I guess it's a very risk-oriented group.

CHRIS: Yeah, kind of. I mean, Haskell is pretty old, I guess but --

JOE: That's fair, yeah.

CHRIS: -- Some of the changes that really make it, it great and usable lately are pretty [inaudible].

JOE: That's interesting. You mentioned this idea -- we kind of skipped over a little bit but thanks, having their own blockchains and that's something that I think that maybe people not actively following this space, which is I will say, a very hard space to keep up for those of us who are actively following it. But those who may just know blockchain through the name of an iced tea company changing or some sensational news article or what have you or just through bitcoin even, but I know that it's not the blockchain. It's not a singular blockchain.

It’s very easy to implement the fundamental structure. It's a linked list, essentially, with the kind of a cryptographic thing that keeps from breaking that link. Those links are inserting new history, I guess the further you go back. I guess people are even exploring different data structures like directed acyclic graphs and stuff and how that could be used to map other domains but the reality is it's a linked list and you can spend up as many of them as you want and you can mine blocks based on all this different criteria.

Bitcoin is a proof of work associated with the minting of a new block and that's been a problem for them as they scale as a currency but it could be a history of anything and the minting of those blocks can be based on anything. You mentioned banks, the financial kind of sector is certainly interested in these smaller private chains but do you think there's a use for that consumer market as well? How do you think that your personal blockchain or set of blockchains might be a factor in the hobbyist of the futurist life?

CHRIS: Oh, wow. That's a different question than I thought. [inaudible] where you're going with that --

JOE: Where do you think I was going?

CHRIS: Well, we're talking about banks and so, the question is now everybody other than banks --

JOE: Well, it could be everybody, including banks too, however you want to take it.

CHRIS: Yeah. There's a much harder question, I think of what in the world we're actually saying when we are talking about blockchain, right? The notion obviously has started with bitcoin but if what you want to do is bitcoin, then you should just be as in bitcoin, so what are we talking about similar bitcoin and the general phrase people have they like to throw in here is Byzantine fault tolerance.

I'm talking about any kind of system that can have multiple participants. We're used to talking about clusters of computers and making systems that can work if one of them fails, if one of them just stops working but now, we're starting to talk about how do we make systems work if one of them gets hacked, then we still have some assurances that the whole system works together as a whole.

JOE: Would you consider Byzantine fault tolerance to be the defining factor of a blockchain because I feel like there's the timestamping element that goes along with it. I feel like they're kind of part and parcel, right?

CHRIS: Kind of but if you're not considering Byzantine faults, if you're only talking about systems where you have benign faults, which is a machine goes down sometimes, then timestamping isn't really a problem because we can just use NTP and we all have a pretty sensible idea of what time it is.

JOE: Time specifically, even just like, I guess order. I always considered sequence to be a massive part of what a blockchain fundamentally was. You have the distributed aspect of the network that gives this sort of resilience to malicious intent but not only is it protected, I guess against demolition and malicious intent by this crowd strength but also just fundamentally through the cryptographic side of it, you can't go in and insert things that didn't happen. Once that order has been said, it's been written in stone, basically, right?

Because the way I understood is there were papers coming out of Bell Labs in the early 90s and those two things set as approaches to this independently and it wasn't until the internet advance so we put them together and we're able to achieve Byzantine fault tolerance through that. Is that, I mean...?

CHRIS: It does help a lot, I think to buck up and think about what the state of research was in the 90s because I think that's something that a lot of people in blockchain space kind of lose sight of. You have a whole lot of people writing papers now who didn't used to be academics until a couple of years ago. It was the early 90s where we started having faxes and we started having what later turned into what's kind of known as raft. Like you said, they solved the ordering problem.

Even something as simple as what we call Lamport clocks which is you have sort of a virtual timestamps and as long as nobody's malicious, if you remove the timestamp forward, then we can all have something that resembles the deterministic forward flow of time. Then, that milestone that I was like to remind people of this in 1999 is when we had the paper practical Byzantine fault tolerance.

JOE: That was '99. You're talking about the... was it Castro and --?

CHRIS: Liskov, yeah.

JOE: Okay. I didn't know it was '99.

CHRIS: Interestingly, the same Liskov that the Liskov substitution principles named for, Barbara Liskov. It's also a distributed systems research.

JOE: That's swell as well. I kind of heard the concept of Byzantine fault tolerance but I never read this paper. I'm also surprised to find that it didn't come out of that same period of the early 90s and it was as far as '99. I haven't read its entirety but I did fall asleep reading it last night.

You mentioned this specifically, I guess, when we're talking today, as a paper that is important. It's the work that we're trying to do at... was it Hijro, I think?

CHRIS: Yeah.

JOE: Yeah, so what kind of work were you doing there and what is important to you, I guess about this paper specifically, when you look at all the research that went into priming the community for the space that we are now in?

CHRIS: When I joined Hijro, I got kind of a difficult and nebulous mission, which was that everyone in and around that space that was trying to sell to banks was if you said the word blockchain, you could get your foot in the door because all the banks were looking at bitcoin and saying, "Well, look, this is clearly something that's going to be big and we don't want to be missing out, so we have to figure out how this applies to us."

JOE: What year is this? They were working this in 2014-ish, is that right?

CHRIS: '15 or '16, I think. The question was trying to figure out what aspect of it was actually what they wanted here. What Hijro is trying to sell them, the details aren't even important for this conversation but we need an interbank solution. We needed a ledger of accounts that 'we weren't a bank so we couldn't be the one holding everyone's money and keeping track of the flow of money in our network.' We were on something that the banks were truly in charge of but we didn't want to necessarily have our platform be owned by a particular bank. We wanted to be the sort of consortium of all of our partners.

JOE: Consortium is a keystone word I think here, that we should definitely come back to that.

CHRIS: Yeah and people talk about, if I use the word consortium blockchain, I think sometimes in contrast with the public blockchain, with the 'free anyone can join' blockchain.

JOE: Yeah. I'm particularly fascinated by this concept. That is a term that is used. I can confirm this. But you're doing that pretty early then because I feel like that concept didn't make it out into, I guess the public understanding, until recently or maybe I'm just behind at times.

CHRIS: Yeah, I guess so. I don't know. When I start working on this, I just spent a couple of months trying to read papers about what was in space and I guess, the only big name that was trying to do something like this was Tendermint.

JOE: Tendermint? Interesting.

CHRIS: You can pick out technologies like this because the magic number is always one-third. They can tolerate Byzantine failure up to one-third of the nodes. That was a theoretical result that was reached, just sort of the best you can do. Before BFT and then BFT is one of those solutions in that category and Tendermint does something similar.

JOE: That, I guess is sort of the background to this paper and it's impacting your life. I guess, what is put forth in this paper is to solve for higher tolerance. Would that be the right way to put it?

CHRIS: Did you say higher tolerance?

JOE: Yes. You're talking about the Byzantine tolerance is 30%, right? With Tendermint? But you're saying that they're doing something similar to that's before in the paper?

CHRIS: The most interesting thing to me, I think is probably, hopefully possible to convey concisely is the rationale behind the one-third number because that took a while for me to really appreciate but I think it really clicked when it did.

One of the hardest intuitions to get people to break, I don't know, way of thinking to shift, I guess is convincing people that consensus is even a hard problem because I had this conversation a lot with people that'd say, "I've got this JavaScript library here, for instance that just lets me broadcast a message to all the nodes in a cluster, so why can I just do that?" Why can't we just use one at a time to do it and if I detected someone's trying to cheat, if I get two different messages from someone that are conflicting, maybe I can just ignore them.

JOE: Not in finance. That's kind of ironic, I guess that you found it difficult to get people to come to a consensus about the importance of consensus.

CHRIS: Right. The basic flow of all these things is we describe them as voting systems. We have voting rounds where each time, like you said the blockchain of the ledger or whatever it is, just a linked list, so the problem of using consensus build database is we're just going to iteratively try to vote or come to consensus on what the next block is. What the next ledger entry should be?

Obviously, since we don't have a synchronized wall clock to go by, we have to assume messages can come in any order. We might all sort of speak up simultaneously and propose different blocks as the next one, at which point we have to start over and retry that. But furthermore, I can send different votes to different people if I'm trying to be malicious and that's where the tricky part comes on.

The rationale for the one-third number, maybe I can just try to come around to that and say it directly then, is that when we take a vote for what the next block is going to be, we need the supermajority. We need two-thirds of the participants to have all said the same thing and the rationale for that is it's actually easier to think of it backwards. Rather than saying, two thirds of the total, what we say is, "If we're going to allow some fixed number of nodes to fail, to behave maliciously --" you know, we traditionally call that number 'F' in the paper, then what we say is we need 3F+1 total nodes to be participating.

JOE: I didn't know that was sort of codified into how conflict is resolved on things like bitcoin during blockchain. It's inherent, I guess.

CHRIS: No. This is the total opposite of what bitcoin and Ethereum are going to do.

JOE: Because I always thought it was just going to be like a majority, I guess but what you are talking about is more like how the Senate would were to pass a resolution to the constitution, like it has to be an exceptional majority. I'm starting to understand why one-third, specifically. It's 3F+1, I guess.

CHRIS: The reason is because for each vote, every time I look at the results of a vote, I have to be able to assume that some number that we called F, of the people that I've heard back from are trying to cheat me. It turns out I need to be sure that the majority of the votes that I've heard back are from people who are actually following the protocol correctly and not lying. We need to be tolerant to two kinds of failure. One is that a node simply goes down and we don't hear from them and we don't receive a vote from them and then the other kind of failure is the Byzantine failure, that they're not following protocol in some way.

The reason I need 3F+1 nodes is because we need to be able to make progress, even if F of these number is we didn't hear from at all because they're down and then, I need 2F+1 votes because I need to take into account the possibility that some F of these votes were from cheaters and then we need to have more honest votes than lying votes.

JOE: That's pretty profound. I definitely going to finish the rest of this paper while conscious later today. I guess we're a little off with regard to math at this point and it's when you said, you spent I guess a month or so just reading papers around the time you started with Hijro and I guess did you stop because I feel like I've read just more white papers than ever thought I would outside of the academic setting, just trying to keep pace with what's been going on, particularly with regard to the web. I don't if you're familiar with like IPFS but these sort of directed acyclic graph things are popping up all over the place and platforms are even now being built on this concept.

I guess, Ethereum feels impractical in a lot of ways. These dime-a-dozen tutorials, when you started talking about the global computer that is Ethereum and the blockchain and it's going to change everything in the internet and you won't have to pay Comcast like some central authority or you just pay for each transactions. The reality of it is every time you do a write against a data store have, first of all, thousands of computers go and verify that and also, you don't want to store your information on a linked list. It's not feasible for storing large data structures and it becomes very expensive for the user and for the person, if you're maintaining a smart contract for the contract itself. These are volatile, all little points of value. It's impractical.

CHRIS: It's definitely a cost that you don't want to incur. In all cases, just a confirmation time is a cost you don't want to incur.

JOE: Absolutely.

CHRIS: There is one nice thing that that you can do in some cases, which is that people is talking about the piggybacking on these blockchains like if I have a system and I just want some extra assurance to keep it honest, then I can do things like periodically publish a hash of my database onto something like bitcoin or Ethereum.

JOE: Yeah. That actually happen with anyone in financial... They do publish stuff in the paper and this was before cryptographic ledgers but to basically prove that this was the state of something, I remembered seeing this somewhere, like there would be in financial news, like there'd be some crazy number or string at the top to verify what was on the string.

CHRIS: Yes. Of course, the irony there is that you really don't need some kind of blockchain if you want to do that because the fact that we're doing that before the blockchain has existed and doubly, it's funny because the first block of the bitcoin blockchain, the genesis block includes in it, I think a New York Times headline, which was intended as proof that Satoshi or whoever didn't spend years mining bitcoin prior to releasing it. It's supposed to be a proof of the time of the first genesis actually was.

It’s funny that we are actually already had this verification system and what that demonstrates is sort of a principle of consensus that I like to talk about which is that as you increase the time scale, consensus becomes an easier and easier problem. I think the reason why something like newspaper headlines are reliable means of a timestamp is just mostly because they're big and slow, because there's only one every day. I think the whole challenge like you said of, how a lot of systems kind of boiled down to having the white paper for bitcoin refers it describes bitcoin as a distributed timestamp server, something along those lines. The reason why you need a new technology to do that, I think so that you could have timestamps that are every of couple minutes, rather than every 24 hours.

JOE: That's a very interesting take on it. I guess, the more time there is, it is easier to reach a consensus. It's just interesting to think about. It's funny as humans like the longer time passes, the less reliable memory is, I guess, less reliable history as we conceive of it, I guess. It's different when you record something than the way that you hold in the brain that sometimes I wonder how much impact that's had on. It's a little ephemeral, I guess but it's interesting.

CHRIS: Yeah. I guess my statement is limited to the on-scale where we can actually fit into memory.

JOE: Right, that most of the times, it's the only relevant scale, I guess, like a blockchain doesn't have use outside of our use of it, inherent to it, so it's going to be seen through that lens, I guess of our use of it. I think it is kind of profound, a thing to think about that I definitely considered. You mentioned using blockchains as adding a little bit of... how do you put it? Like truthiness, I guess, we'll say. I know that's not how you put it but adding a little bit of security, maybe around something else but the reality is you can get away with that on a number of other levels. I think that's important and interesting to think about.

There seems to be this trend now talking about a blockchain as part of a bigger picture or consortium blockchain or a consortia of blockchains, right? Because a consortia would be multiple and then a consortium would be... No, a consortium would be a single grouping, consortia would be multiple groups.

Basically, going back to the problem you're trying to solve with Hijro, you have multiple banks and I believe eventually, I don't know if you work on it, there was a protocol that came out of that company to unify these blockchains, like a few of them. They demoed and everything. That, I think gives you some power with regard to access control but again, I guess, that's not a thing that you really need consensus for. So, where does it fit in? Aside from things like voting and transparent finance for maybe a political cause or in the case of bitcoin, just finance in general. In bitcoin, I feel like we got Mongo DB super hard in the sense that it just got applied to every domain and it applies to very, very few.

CHRIS: My boss at Hijro, Lamar Wilson really like to say that people talked about blockchain like it was hot sauce and they sort of sprinkle it on everything to make it better.

JOE: That's sad.

CHRIS: I guess, two answer to that one. One of the places where it absolutely captivates people's imaginations too far and doesn't work and then places where it doesn't work, so I want to start with the first here because the biggest mistake that people make is that there was this notion of tokenization that came out of Ethereum, where anyone could make a smart contract that represented something and now, also that I can trade digitally. Just like it's money or some kind of digital asset, so people want to talk about putting your car, putting your house on the blockchain or selling it there.

But it's just shocking how many times I had to remind people that if I make a smart contract that represents cars and I put my VIN number on it and I transfer you my car, at Ethereum contract in an exchange for a bitcoin, if I call the police and report my car stolen, they're not going to look at the Ethereum contract, right?

JOE: Yeah. Man, you're really right. People don't think about that enough. If your car is in the blockchain, your car still on the block.

CHRIS: What we had realize when we're selling solutions like this is that they're great for some reasons but you need actual legal agreements to underpin things when you actually make connection to the real world. The magic of bitcoin that can't really be replicated is that the coin actually didn't need a pinning to the real world because the thing bitcoin was running was itself. It just depended on hoping that people were going to find the coin and ledger valuable intrinsically and bitcoin never really purported to control things in the real world.

JOE: I guess, definitely not in the paper. There are some place that can buy in from some very specific elements of society that sort of cemented its place as useful but we don't really need to go to that road, I guess. I don't know. You know, my roommate is a lawyer and we have this conversation often and I feel like if we go down law and cryptography, we're going to be talking for too long, where we are at currently.

CHRIS: Right and that wasn't your question anyway. It was just what I respond to easiest because being a critic is always the easier thing to do.

JOE: I can feel you there.

CHRIS: One of the interesting things that I never even found too much about but I noticed this in a couple of passing references as I was reading stuff about Byzantine fault tolerance in general is that it seems to have some application in things like flight control systems and space ships because when you think about a computer that you're going to send into space, you have two things that Byzantine fault tolerance applies to directly. One is you need a lot of redundancy. You need these control systems, maybe you have a dozen things computing the same result because you can't replace the hardware when once you shot something to space.

The second thing is once you've sent something outside the atmosphere, all of the sudden, you're being bombarded with a lot more cosmic rays than you were before. Now, you actually really do this idea that computers can fail, not just by stopping but by producing wrong results. All of a sudden, it becomes a lot more real because you actually have physics slipping a bit at your computers.

JOE: I don't even think you have to go as far as space if you talk about just like a fleet of something, like self-trading cards. I suppose, in domain where there is an interplanetary file system, it's good to specify the planet we're talking about. Just having worked a little bit with robots in college, they lie all the time and they produce bad data constantly, so not even bad actors just incompetent actors, I guess could definitely... This is something that has to be, I guess on our minds as we move forward as the society that has more connected devices, which I think as much as I would love to have left this conversation off in outer space, I think bringing it around to the internet of things, which is sort of where this all began months and months ago is probably a good place to stop meandering through these cryptographic weeds. You can probably put a pin in this.

I think we've been talking about for a while now, I guess and just kind of trying to see what it is and where the applications are. It's constantly changing and never clear, I think is the conclusion that I've come to. I don't know. I think, just kind of shooting the breeze about it is a fitting end to a series of Frontside engagements in this space, for the time being.

CHRIS: I've seen several people try to tackle the space of how to stop relying on things like Google Drive to store our data because I think a lot of us have realized that we're tired of losing all of our family photos every time a hard drive dies but a lot of people are uncomfortable with trusting Google with everything. This to me seems like a perfect opportunity for people to start building redundant systems among their home and friends.

JOE: Yeah, I completely agree. I'm actively trying to do exactly that right now.

CHRIS: Oh, cool. And you don't necessarily want your cluster of machines that's running on all of your family's computers to be able to go down if your 10-year old get some virus, right?

JOE: Right and also, there's definitely things that you want just within your home or even just within your section of the home. I guess you could layer chains, to kind of manage those interactions?

CHRIS: Sure. I'm not exactly sure what you mean by layering chains.

JOE: You could have consortia in this case. If you had like a hypervisor, almost like a control notice, essentially or some type of view from above of this situation, you could say, think of it as a family scenario. We have three different houses on this call that all belong to our immediate family and cousins and whatever and it's like, me and my siblings, we have information that we all want just within the siblings. We don't want Mom and Dad to know. We don't want the cousins to know, so you could basically use like a blockchain to kind of date access to data that is held within that consortium and then the consortia could communicate amongst each other. Only the pertinent information that they wanted to allow access to at that time and then, internally of course, you could have all these different mechanisms for how you actually store that data or how you actually serve it up. It's pretty complicated.

CHRIS: Yeah, I think you made a lot of sense, though.

JOE: Yeah, cool. I'm hoping so. There's been some work on it out of Microsoft, actually.

CHRIS: On the files storage problem, specifically?

JOE: I guess this is like with a smart home and kind of just teaching devices to cooperate and ask each other. If you had a section of connected devices that maybe were related to the workflow that a human being might go through to get groceries or something and then a section that's related to doing laundry or whatever, eventually, they would learn to communicate in the laundry grouping and could say, "Hey, grocery people. We're out of soup," or something like that.

It's sort of almost happened organically, I guess. I had not actually felt like I found that paper. I've only found references to it. This is where I need to get something like academic access but that was interesting stuff. I don't know how I end up here, either. This has always happening when you're talking about this domain. Anyway --

CHRIS: People's ideas, it's just sort of generally inspiring concept so people is following you everywhere.

JOE: Yeah, it's heartwarming. You know, with my ICT, I could look back and see exactly where I usually came from than [inaudible], the name of the farmer who grew with. I don't know. It'd be so much easier to fake most things, really when you think about it.

On that note, I hope that this conversation was... I know that there was no JavaScript and I apologize for that but I hope that our audience finds it interesting on some level and I want to thank you for your time. Chris, it was really great talking to you and getting your take on these things as somebody who's been in the industry for a while. Definitely, some fascinating points to consider and definitely, I will finish that white paper, probably this evening because it's pretty cool.

If anybody in the audience has anything they'd like to ask you about pertinent to this conversation or anything else, where is a good place to get a hold of you?

CHRIS: For me, it's mostly Twitter. I'm @chris__martin. I'm also at Type Classes, if you want to talk to me about our new business.

JOE: Cool. This has been Episode 104, I believe of The Frontside Podcast. Frontside, we're a consultancy based in Austin, Texas and we love writing elegant, sustainable code and just producing good stuff, really. I think that's what we're all about. I think, we can agree at least, that's a core tenet of what we do and if you would like us to produce some good stuff for you, feel free to get in touch with us.

Also, feel free to reach out via email if you have any ideas for future topics or any feedback about this episode. I also want to thank Mandy for producing this episode. You can catch us next week, I believe for our talk with Brian Douglas on Probot and Robert will be hosting that one, as far as I know. Thank you all for your time and feel free to reach out. This has been The Frontside Podcast. I'm Joe LaSala. Chris Martin, thank you for joining us and have a good day, everybody.

Listen to our podcast:

Listen on Apple Podcasts