Notes from an Ultra-Running multidisciplinary PhD student

Let's be honest here: I can topic-drop with the best of them.

Oh, you run half-marathons? Yeah, I ran a 50-mile a couple years ago. I didn't even die! 

You like to listen to music? That's cool! I studied classical piano performance under Dr. Joan Sawyer.

You put ethanol in your fuel tank? Neat! I helped a couple guys start a biodiesel production company a few years back; we built several factories around Tennessee and patented our technology.

You read an article about bitcoin once? Oh, sure - I've tinkered with my own home-made cryptocurrency trading bots. Nothing too serious.

You built a circuit board for your research? Sounds fun. My PhD research pertains to the complex connections between social systems and engineered systems; I'm particularly interested in characterizing and influencing user behavior in socio-technical systems.

Hello, Steem community! My name is Philip N. Brown, and I'm here to explore Steem and see how I can contribute. I've been casually interested in crypto-finance for a few years now; my most active participation was with Bitshares and MemoryCoin; you can find me on several major crypto forums as user "biophil." I'm going to try to keep this fairly brief, but I'd like to give a cursory outline of my interests.

Right now, I'm first and foremost a PhD student. I'm in an electrical engineering program at UCSB, and my research bridges various aspects of economics, computer science, and control theory. Fundamentally, I'm interested in what are being called "socio-technical systems," or engineered systems with a strong social component. The unifying characteristic here is that the performance of the system depends heavily on the actions of its users; I believe the purest examples of this type of system can be found in crypto-finance. Over the past several years, we've seen some fascinating crypto projects emerge: Bitcoin decentralized payments, and then a blizzard of projects (Counterparty, Nxt, and BitShares are some of the earliest examples) worked to decentralize asset exchanges. Now, the projects are ever-more ambitious; Ethereum and Steem are great examples. 

In all these settings, the goal has been to take a system that's currently implemented in a centralized fashion (person-to-person payments, asset exchanges, social networks) and implement them in a leaderless, cryptographically-secured manner (Bitcoin, BitShares, and Steem, respectively). To do this, two interrelated problems must be solved: 

1. The "technical" problem

That is, how do we design software that can automate the system in question in a decentralized way? Bitcoin gave us one solution: the blockchain. I'm violently oversimplifying, but if a blockchain is implemented well, it can provide the technical means to accomplish the task.

2. The "social" problem

Here, the issue is that decentralization introduces a great deal of vulnerability to strategy. Consider the payments system: in the centralized version (think Paypal), all of the system's decisions are being controlled by a single actor: the Paypal engine. This engine sits in one physical location, and it's programmed for one task: facilitate money transfers between customers (again, I'm oversimplifying). The engine has no incentive to do anything other than what it is programmed to do. If you decentralize this and make it leaderless, then the incentive problem becomes potentially very interesting. In bitcoin, decentralization means putting many copies of the "bitcoin engine" on many different computers under the control of many different people all over the world, and designing the system in such a way that no one person has an incentive to operate the engine in any way other than how it was designed. Bitcoin accomplishes this in part via their proof-of-work mining system; other crypto-ecosystems have devised other methods (e.g., "forging" in Nxt and "witnesses" in BitShares).

This second problem is the interesting one to me. In the academic algorithmic game theory community, there is a concept known as the "Price of Anarchy:" this is a measure of the relative cost of decentralization. The key insight here is that centralized schemes "work better" than decentralized ones, so we should be aware of what we're giving up in transitioning to a decentralized world. In this context, the design question that interests me most is this: How can we, as practitioners and academics, design decentralized protocols which leverage individual agents' self-interested behavior to achieve good system-wide performance?

In the coming months, I'm going to be posting on here in an effort to start voicing an academic's perspective on some of these questions. In many ways, practitioners and academics are supposed to come at problems from opposite directions: practitioners are supposed to solve the immediate problems, and academics are supposed to talk about (and occasionally solve) the overarching problems. Practitioners work in specificity, academics work in generality. In my career I've done both, so I hope I can bridge the spectrum and offer valuable insights to both sides.