Being a student again…

1

One of the sessions of our freshman seminar that I’ve grown to particularly like is the last one, where the students are responsible for coming up with a topic, putting together the reading list, and leading the discussion. It’s always interesting to find out what they think we missed during the semester, and it is fun to be a student again, getting a chance to read up on and think about something new.

This time around, the students decided to run a class session on bitcoin and blockchain. I was delighted; I’d been planning on taking some time to learn about these technologies, and now I had the chance to do so with others finding the right readings and study time built-in. The students put together a great selection of readings and videos, so I got to dive in.

I want to look into the technology more deeply, but what I’ve seen so far doesn’t really impress me. There are some interesting aspects to it; I like the idea of provably unchangeable ledgers (even though it isn’t all that new) and find the incentive system clever. In theory, it should all work fine. But in practice, I don’t see how it is going to scale.

In a distributed system, scale is the hard part. Getting something that works for 2 machines is a lot harder than getting something to work on a single machine. Getting something to work on thousands of machines is a lot harder still. And where things really get hard is when you try to deal with all of the possible faults that can occur in the system– from machines going down (the simplest form of fault) to networks losing packets to partitions to software bugs.

Blockchain seems to start with the idea that you can get agreement on a distributed database; the base paper points out that this requires agreement by 51% of the machines. The first thing to notice is that this means that the system is only worried about simple faults like machines crashing, since a well-known proof in distributed systems shows that if you are worried about byzantine faults (like those caused by software, or someone trying to subvert the system) you need agreement of 2/3rds of the participants in the system (plus 1). I’m also not sure how, in a system that is as open-ended as the blockchain system, you know how many machines are taking part. Which is a pre-requisite for knowing when you have reached agreement with 51% of them.

Then there is the use of time in the blockchain system. Time is exceptionally tricky in a large-scale distributed system (you get genuine relativistic effects), so assuming even roughly synchronized clocks is generally a bad idea. Looking at how they use time, it is also pretty clear that all that is needed is a sequence number, which is easier to implement. But the folks doing blockchain seem to not understand this.

My overall impression is of a system that combines some interesting cryptographic techniques in a distributed system built on a large set of naive or incorrect assumptions. Which wouldn’t be a problem if the system were being used for experiments. But I worry when such a system is being used for money, or contracts, or other legal matters, since then any but or oversight could lead to an exploit.

And when I try to think of how to change the system so that it doesn’t have the problems I see, I’m stumped. At base, I don’t know how you scale a system based on an assumption of computational difficulty. I feel like I’m watching the modern equivalent of the children’s crusades– well-intentioned, with passionate advocates, but doomed not to end well because it isn’t tied to the realities of the situation.

So I’ll dig some more to see if I can find where I’m wrong. I hope I am, but am afraid that I’m not. Til then, I think I’ll not invest in this particular technology.

I would like to thank all of the seminar participants for being great teachers, both in the last session on bitcoin and blockchain and during the rest of the semester. You are a remarkable group of people, and I hope you stay in touch with us and each other. The truth about Harvard is that the faculty learn much more from the students than the other way around, and this seminar was a great example of that. Drop by, drop me a note, but don’t drop out of my life…I miss you all already.

previous:
Caught between bad and worse…
next:

1 Comment »

  1. Mike Smith

    December 6, 2017 @ 4:52 pm

    1

    Thanks, Jim, for being the incredible, dedicated, thoughtful, smart co-instructor that you always are. It’s always fun, and the students never cease to amaze me. I’ll try very hard not to let this adventure lapse until we teach it again.

    And thanks for clearing up my distributed systems questions. Great post!

Leave a Comment