Why would I ever need that?

Today was the last session of this fall’s Freshman Seminar. I can’t believe we have reached the end of the semester. Each year’s class is wonderful, but there was something about this group of students. Engaged. Funny. Thoughtful. Spirited. Excited about the future and the potential it holds for all of us. I hope each of you keeps in touch and calls on me when you have something to share or want to just talk through different opportunities. Thank you for making 50N something to which I looked forward each and every week.

On the other hand, as you probably sensed in class today, I am amazed that the exuberance around blockchain and crypto-currencies continues to grow. When will we see this exuberance pop? I don’t know. Jim would know better than me, but there are a number of hard distributed computing problems that seem to have been swept under the rug, which might be ok in small networks, but worry me in large ones. I was also struck while reading with the lack of careful consideration of the threats against blockchain and the systems built upon it. Maybe such careful threat modeling is done elsewhere, but it continues to feel like we’re repeating the same problematic approach to the world that we saw throughout the development of the Internet and its applications: rush to trumpet the functionality and worry later about the threats.

The first Bitcoin paper says that double spends are not a problem because you can ignore them. But can an adversary flood the network with double spends? Would such an approach become a type of denial of service? Is a double spend request just a normal timing problem in the network, or is it something nefarious? This is just one example I wish I had seen considered.

In a related way, I found the Ether Thief paper fascinating. It appeared that no one deeply involved with the development of Ethereum ran a tabletop exercise to determine and practice what every person involved should do when the inevitable attack happens. You hope your bank is never robbed, but you can bet your bottom dollar that banks run tabletop exercises regularly to make sure that everyone knows what to do when a robbery happens. I suggest that you ask before you put your money into one of these blockchain-based systems what they’ve done to protect themselves against theft and how often they practice doing what they’ll do during an actual theft. No theft will be a textbook theft in all ways, but preparation matters and can help with prevention. The Harvard Kennedy School has experts in the field of Crisis Leadership, and while it might be no fun to be grilled by the likes of Professor Dutch Leonard in one of these mock sessions (from experience), you learn a lot about what you’re ready to handle and what you need to prepare yourself to handle.

Lastly, I’d like to touch upon the Iansiti and Lakhani paper. I thought it was quite good for what it was: an argument against blockchain as a disruptive technology. However, I don’t think blockchain is like TCP/IP. TCP/IP had competitors, but forks of the technology weren’t a long-term issue. If you found a mistake in the current implementation of TCP/IP, you fixed it and everything easily moves over to the new implementation. If you had a dispute about which implementation works better, you put both out there and one eventually won out (everyone moved over to it). Of course, some things are harder to change than others (e.g., consider how long it took to move from IPv4 to IPv6). Even so, we haven’t experienced in TCP/IP the threat of many persistent forks in the way we’re seeing in crypto-currencies. The network effect made the Internet take off quickly and that was fueled by basically a dominant foundational technology. I am not so convinced in the blockchain world.

But then, I’m old. I have often been wrong.