In the first part of this series, we talked about how the internet allows us to create decentralized corporations, automatons that exist entirely as decentralized networks over the internet, carrying out the computations that keep them “alive” over thousands of servers. As it turns out, these networks can even maintain a Bitcoin balance, and send and receive transactions. These two capacities: the capacity to think, and the capacity to maintain capital, are in theory all that an economic agent needs to survive in the marketplace, provided that its thoughts and capital allow it to create sellable value fast enough to keep up with its own resource demands. In practice, however, one major challenge still remains: how to actually interact with the world around them.
Getting Data
The first of the two major challenges in this regard is that of input – how can a decentralized corporation learn any facts about the real world? It is certainly possible for a decentralized corporation to exist without facts, at least in theory; a computing network might have the Zermelo-Fraenkel set theory axioms embedded into it right from the start and then embark upon an infinite loop proving all possible mathematical theorems – although in practice even such a system would need to somehow know what kinds of theorems the world finds interesting; otherwise, we may simply learn that a+b=b+a, a+b+c=c+b+a, a+b+c+d=d+c+b+a and so on. On the other hand, a corporation that has some data about what people want, and what resources are available to obtain it, would be much more useful to the world at large.
Here we must make a distinction between two kinds of data: self-verifying data, and non-self-verifying data. Self-verifying data is data which, once computed on in a certain way, in some sense “proves” its own validity. For example, if a given decentralized corporation is looking for prime numbers containing the sequence ‘123456789’, then one can simply feed in ‘12345678909631’ and the corporation can computationally verify that the number is indeed prime. The current temperature in Berlin, on the other hand, is not self-verifying at all; it could be 11’C, but it could also just as easily be 17’C, or even 231’C; without outside data, all three values seem equally legitimate.
Bitcoin is an interesting case to look at. In the Bitcoin system, transactions are partially self-verifying. The concept of a “correctly signed” transaction is entirely self-verifying; if the transaction’s signature passes the elliptic curve digital signature verification algorithm, then the transaction is valid. In theory, you might claim that the transaction’s signature correctness depends on the public key in the previous transaction; however, this actually does not at all detract from the self-verification property – the transaction submitter can always be required to submit the previous transaction as well. However, there is something that is not self-verifying: time. A transaction cannot spend money before that money was received and, even more crucially, a transaction cannot spend money that has already been spent. Given two transactions spending the same money, either one could have theoretically come first; there is no way to self-verify the validity of one history over the other.
Bitcoin essentially solves the time problem with a computational democracy. If the majority of the network agrees that events happened in a certain order, then that order is taken as truth, and the incentive is for every participant in this democratic process to participate honestly; if any participant does not, then unless the rogue participant has more computing power than the rest of the network put together his own version of the history will always be a minority opinion, and thus rejected, depriving the miscreant of their block revenue.
In a more general case, the fundamental idea that we can gleam from the blockchain concept is this: we can use some kind of resource-democracy mechanism to vote on the correct value of some fact, and ensure that people are incentivized to provide accurate estimates by depriving everyone whose report does not match the “mainstream view” of the monetary reward. The question is, can this same concept be applied elsewhere as well? One improvement to Bitcoin that many would like to see, for example, is a form of price stabilization; if Bitcoin could track its own price in terms of other currencies or commodities, for example, the algorithm could release more bitcoins if the price is high and fewer if the price is low – naturally stabilizing the price and reducing the massive spikes that the current system experiences. However, so far, no one has yet figured out a practical way of accomplishing such a thing. But why not?
The answer is one of precision. It is certainly possible to design such a protocol in theory: miners can put their own view of what the Bitcoin price is in each block, and an algorithm using that data could fetch it by taking the median of the last thousand blocks. Miners that are not within some margin of the median would be penalized. However, the problem is that the miners have every incentive, and substantial wiggle room, to commit fraud. The argument is this: suppose that the actual Bitcoin price is 114 USD, and you, being a miner with some substantial percentage of network power (eg. 5), know that there is a 99.99 chance that 113 to 115 USD will be inside the safe margin, so if you report a number within that range your blocks will not get rejected. What should you say that the Bitcoin price is? The answer is, something like 115 USD. The reason is that if you put your estimate higher, the median that the network provides might end up being 114.05 BTC instead of 114 BTC, and the Bitcoin network will use this information to print more money – increasing your own future revenue in the process at the expense of existing savers. Once everyone does this, even honest miners will feel the need to adjust their estimates upwards to protect their own blocks from being rejected for having price reports that are too low. At that point, the cycle repeats: the price is 114 USD, you are 99.99 sure that 114 to 116 USD will be within the safe margin, so you put down the answer of 116 USD. One cycle after that, 117 USD, then 118 USD, and before you know it the entire network collapses in a fit of hyperinflation.
The above problem arose specifically from two facts: first, there is a range of acceptable possibilities with regard to what the price is and, second, the voters have an incentive to nudge the answer in one direction. If, instead of proof of work, proof of stake was used (ie. one bitcoin = one vote instead of one clock cycle = one vote), then the opposite problem would emerge: everyone would bid the price down since stakeholders do not want any new bitcoins to be printed at all. Can proof of work and proof of stake perhaps be combined to somehow solve the problem? Maybe, maybe not.
There is also another potential way to resolve this problem, at least for applications that are higher-level than the underying currency: look not at reported market prices, but at actual market prices. Assume, for example, that there already exists a system like Ripple (or perhaps something based on colored coins) that includes a decentralized exchange between various cryptographic assets. Some might be contracts representing assets like gold or US dollars, others company shares, others smart property and there would obviously also be trust-free cryptocurrency similar to Bitcoin as well. Thus, in order to defraud the system, malicious participants would not simply need to report prices that are slightly incorrect in their favored direction, but would need to push the actual prices of these goods as well – essentially, a LIBOR-style price fixing conspiracy. And, as the experiences of the last few years have shown, LIBOR-style price fixing conspiracies are something that even human-controlled systems cannot necessarily overcome.
Furthermore, this fundamental weakness that makes it so difficult to capture accurate prices without a crypto-market is far from universal. In the case of prices, there is definitely much room for corruption – and the above does not even begin to describe the full extent of corruption possible. If we expect Bitcoin to last much longer than individual fiat currencies, for example, we might want the currency generation algorithm to be concerned with Bitcoin’s price in terms of commodities, and not individual currencies like the USD, leaving the question of exactly which commodities to use wide open to “interpretation”. However, in most other cases no such problems exist. If we want a decentralized database of weather in Berlin, for example, there is no serious incentive to fudge it in one direction or the other. Technically, if decentralized corporations started getting into crop insurance this would change somewhat, but even there the risk would be smaller, since there wowuld be two groups pulling in opposite directions (namely, farmers who want to pretend that there are droughts, and insurers who want to pretend that there are not). Thus, a decentralized weather network is, even with the technology of today, an entirely possible thing to create.
Acting On The World
With some kind of democratic voting protocol, we reasoned above, it’s possible for a decentralized corporation to learn facts about the world. However, is it also possible to do the opposite? Is it possible for a corporation to actually influence its environment in ways more substantial than just sitting there and waiting for people to assign value to its database entries as Bitcoin does? The answer is yes, and there are several ways to accomplish the goal. The first, and most obvious, is to use APIs. An API, or application programming interface, is an interface specifically designed to allow computer programs to interact with a particular website or other software program. For example, sending an HTTP GET request to http://blockchain.info/address/1AEZyM6pXy1gxiqVsRLFENJLhDjbCj4FJz?format=json sends an instruction to blockchain.info’s servers, which then give you back a file containing the latest transactions to and from the Bitcoin address 1AEZyM6pXy1gxiqVsRLFENJLhDjbCj4FJz in a computer-friendly format. Over the past ten years, as business has increasingly migrated onto the internet, the number of services that are accessible by API has been rapidly increasing. We have internet search, weather, online forums, stock trading, and more APIs are being created every year. With Bitcoin, we have one of the most critical pieces of all: an API for money.
However, there still remains one critical, and surprisingly mundane, problem: it is currently impossible to send an HTTP request in a decentralized way. The request must eventually be sent to the server all in one piece, and that means that it must be assembled in its entirety, somewhere. For requests whose only purpose is to retrieve public data, like the blockchain query described above, this is not a serious concern; the problem can be solved with a voting protocol. However, if the API requires a private API key to access, as all APIs that automate activities like purchasing resources necessarily do, having the private key appear in its entirety, in plaintext, anywhere but at the final recipient, immediately compromises the private key’s privacy. Requiring requests to be signed alleviates this problem; signatures, as we saw above, can be done in a decentralized way, and signed requests cannot be tampered with. However, this requires additional effort on the part of API developers to accomplish, and so far we are nowhere near adopting signed API requests as a standard.
Even with that issue solved, another issue still remains. Interacting with an API is no challenge for a computer program to do; however, how does the program learn about that API in the first place? How does it handle the API changing? What about the corporation running a particular API going down outright, and others coming in to take its place? What if the API is removed, and nothing exists to replace it? Finally, what if the decentralized corporation needs to change its own source code? These are problems that are much more difficult for computers to solve. To this, there is only one answer: rely on humans for support. Bitcoin heavily relies on humans to keep it alive; we saw in March 2013 how a blockchain fork required active intervention from the Bitcoin community to fix, and Bitcoin is one of the most stable decentralized computing protocols that can possibly be designed. Even if a 51 attack happens, a blockchain fork splits the network into three, and a DDoS takes down the five major mining pools all at the same time, once the smoke clears some blockchain is bound to come out ahead, the miners will organize around it, and the network will simply keep on going from there. More complex corporations are going to be much more fragile; if a money-holding network somehow leaks its private keys, the result is that it goes bankrupt.
But how can humans be used without trusting them too much? If the humans in question are only given highly specific tasks that can easily be measured, like building the fastest possible miner, then there is no issue. However, the tasks that humans will need to do are precisely those tasks that cannot so easily be measured; how do you figure out how much to reward someone for discovering a new API? Bitcoin solves the problem by simply removing the complexity by going up one layer of abstraction: Bitcoin’s shareholders benefit if the price goes up, so shareholders are encouraged to do things that increase the price. In fact, in the case of Bitcoin an entire quasi-religion has formed around supporting the protocol and helping it grow and gain wider adoption; it’s hard to imagine every corporation having anything close to such a fervent following.
Hostile Takeovers
Alongside the “future proofing” problem, there is also another issue that needs to be dealt with: that of “hostile takeovers”. This is the equivalent of a 51 attack in the case of Bitcoin, but the stakes are higher. A hostile takeover of a corporation handling money means that the attacker gains the ability to drain the corporation’s entire wallet. A hostile takeover of Decentralized Dropbox, Inc means that the attacker can read everyone’s files (although hopefully the files are encrypted, although in the case the attacker can still deny everyone their files). A hostile takeover of a decentralized web hosting company can lead to massive losses not just for those who have websites hosted, but also their customers, as the attacker gains the ability to modify web pages to also send off customers’ private data to the attacker’s own server as soon as each customer logs in. How might a hostile takeover be accomplished? In the case of the 501-out-of-1000 private key situation, the answer is simple: pretend to be a few thousand different servers at the same time, and join the corporation with all of them. By forwarding communications through millions of computers infected by a botnet, this is easy to accomplish without being detected. Then, once you have more than half of the servers in the network, you can immediately proceed to cash out.
Fortunately, the presence of Bitcoin has created a number of solutions, of which the proof of work used by Bitcoin itself is only one. Because Bitcoin is a perfect API for money, any kind of protocol involving monetary scarcity and incentives is now available for computer networks to use. Proof of stake, requiring each participating node to show proof that it controls, say, 100 BTC is one possible solution; if that is done, then implementing a hostile takeover would require more resources than all of the legitimate nodes committed together. The 100 BTC could even be moved to a multisignature address partially controlled by the network as a surety bond, both discouraging nodes from cheating and giving their owners a great incentive to act and even get together to keep the corporation alive.
Another alternative might simply be to allow the decentralized corporation to have shareholders, so that shareholders get some kind of special voting privileges, along with the right to a share of the profits, in exchange for investing; this too would encourage the shareholders to protect their investment. Making a more fine-grained evaluation of an individual human employee is likely impossible; the best solution is likely to simply use monetary incentives to direct people’s actions on a coarse level, and then let the community self-organize to make the fine-grained adjustments. The extent to which a corporation targets a community for investment and participation, rather than discrete individuals, is the choice of its original developers. On the one hand, targeting a community can allow your human support to work together to solve problems in large groups. On the other hand, keeping everyone separate prevents collusion, and in that way reduces the likelihood of a hostile takeover.
Thus, what we have seen here is that very significant challenges still remain before any kind of decentralized corporation can be viable. The problem will likely be solved in layers. First, with the advent of Bitcoin, a self-supporting layer of cryptographic money exists. Next, with Ripple and colored coins, we will see crypto-markets emerge, that can then be used to provide crypto-corporations with accurate price data. At the same time, we will see more and more crypto-friendly APIs emerge to serve decentralized systems’ needs. Such APIs will be necessary regardless of whether decentralized corporations will ever exist; we see today just how difficult cryptographic keys are to keep secure, so infrastructure suitable for multiparty signing will likely become a necessity. Large certificate signing authorities, for example, hold private keys that would result in hundreds of millions of dollars worth of security breaches if they were ever to fall into the wrong hands, and so these organizations often employ some form of multiparty signing already.
Finally, it will still take time for people to develop exactly how these decentralized corporations would work. Computer software is increasingly becoming the single most important building block of our modern world, but up until now search into the area has been focused on two areas: artificial intelligence, software working purely on its own, and software tools working under human beings. The question is: is there something in the middle? If there is, the idea of software directing humans, the decentralized corporation, is exactly that. Contrary to fears, this would not be an evil heartless robot imposing an iron fist on humanity; in fact, the tasks that the corporation will need to outsource are precisely those that require the most human freedom and creativity. Let’s see if it’s possible.
Supplementary reading: Jeff Garzik’s article on one practical example of what an autonomous corporation might be useful for